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

[Arun Sharma]

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.

 -Arun

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=packages/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=d04dc94
>> > 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
>