Re: [Libunwind-devel] Backtrace performance on x86-64 based on Dwarf info

[Milian Wolff]

On Sunday 07 September 2014 16:03:53 Arun Sharma wrote:
> Just to confirm: is this the patch you're referring to?
> http://paste.ubuntu.com/8278768/
> 
> Doesn't break anything on my end. I'll push it once you confirm.

Hey Arun,

yes, that's the one. Please push it - many thanks.

Bye

> On Mon, Aug 25, 2014 at 4:41 PM, Milian Wolff <address@hidden> wrote:
> > On Monday 25 August 2014 11:46:12 Milian Wolff wrote:
> >> On Thursday 19 June 2014 23:50:25 Lassi Tuura wrote:
> >> > Hey,
> >> 
> >> Hey Lassi, Arun.
> >> 
> >> I want to revive this thread after my long absence in the hope to get the
> >> situation improved upstream. Locally, I've been running with the patch of
> >> the previous mail for some time now and it works very well in my case.
> >> 
> >> > Thanks for testing that. Note though that as the comment immediately
> >> > above
> >> > says, x86_64 ABI says the last frame should have null RBP (IIRC, that's
> >> > 3.4.1 Initial Stack and Register State). Can you possibly find out why
> >> > that doesn't hold on your platform?
> >> 
> >> Do you have any suggestions on how to do that? I.e. what should I look
> >> at?
> >> Specific compile options for libc? You can find the PKGBUILD that is used
> >> on ArchLinux here:
> >> 
> >> https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=package
> >> s/g libc
> >> 
> >> That contains the configure invocation with all its arguments and the
> >> patches that are applied previously.
> >> 
> >> > The code I was thinking about is apply_reg_state in src/dwarf/Gparser.c
> >> > where the DWARF_IS_NULL_LOC (c->loc[c->ret_addr_column]) conditions
> >> > should
> >> > have kicked in to set RIP for the next step to 0, which I vaguely
> >> > recall
> >> > caused the unwind to terminate at that step. But maybe there was a
> >> > change
> >> > to allow unwinding to continue with RIP == 0. (Arun do you recall
> >> > details
> >> > on that? For example
> >> > http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=commitdiff;h=d04d
> >> > c94
> >> > cc 2b0141f06ed9de1665ab89a3f549e0b - I vaguely recall we talked about
> >> > it.)
> >> 
> >> Any news on that Arun? I'll also try to figure out whats going on and why
> >> this is not kicking in.
> > 
> > Quick update, I looked at it a bit more with the following test program:
> > 
> > ~~~~~~~~~~~~~~~~
> > #include <stdio.h>
> > 
> > #define UNW_LOCAL_ONLY
> > #include <libunwind.h>
> > 
> > int main()
> > {
> > 
> >     const int MAX_SIZE = 128;
> >     void* data[MAX_SIZE];
> >     for (int repeat = 0; repeat < 2; ++repeat) {
> >     
> >         int size = unw_backtrace(data, MAX_SIZE);
> >         printf("\ntrace size: %d\n\n", size);
> >         for (int i = 0; i < size; ++i) {
> >         
> >             printf("%p\n", data[i]);
> >         
> >         }
> >         printf("\n");
> >     
> >     }
> >     return 0;
> > 
> > }
> > ~~~~~~~~~~~~~~~~
> > 
> > Running it with UNW_DEBUG_LEVEL=15 env var set, I get the output you find
> > attached in original.log. I've added debug output to apply_reg_state when
> > the IP set set to zero, i.e.: apply_reg_state:818: SETTING IP TO ZERO
> > 
> > You'll see that the IP _is_ set to zero but unwinding is continued
> > thereafter, even though "DWARF spec says undefined return address
> > location means end of stack." (dwarf/Gparser.c). The garbage "0" ip is
> > returned at the end.
> > 
> > With the patch to also check for this in x86_64/Gstep.c applied, the
> > output
> > changes to patched.log and everything behaves correctly, as far as I can
> > see. The garbage "0" ip is skipped, i.e. unwind stops properly and
> > everything is cached and fast.
> > 
> > So, can we get this patch in, or should we add a "last_frame" to
> > dwarf_cursor which is set to 1 when the return address location is
> > undefined? This would mean changes all over the place though, something
> > which I'd not be comfortable with as I cannot test other architectures
> > easily. Esp. the question whether checking for ip == 0 is valid on e.g.
> > x86 or not is something I cannot decide.
> > 
> > Bye
> > --
> > Milian Wolff
> > address@hidden
> > http://milianw.de
> > 
> > _______________________________________________
> > Libunwind-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/libunwind-devel

-- 
Milian Wolff
address@hidden
http://milianw.de