Re: [PATCH] Fix dwarf2 unwinding through futex functions v2

["Carlos O'Donell" <carlos at redhat dot com>]

On 03/17/2014 01:04 PM, Andi Kleen wrote:
>> My last comment was November 11th 2013:
>> https://sourceware.org/ml/libc-alpha/2013-11/msg00194.html
>> ~~~
>> I'm OK with this patch as long as you've tried to at least debug a
>> program built with these new libpthread code and you can unwind through
>> them. That is to say build some application with the newly built glibc
>> e.g. -Wl,--dynamic-linker=xxx -Wl,-rpath=xxx:xxx, and you can break on
>> some instruction deep in the lock sequence and backtrace correctly.
>> ~~~
>>
>> If you did this verification then I'm happy with you checking it in.
> 
> Just revisiting this sorry.
> 
> I did the test originally. However I don't have commit access to the glibc
> git repository, so someone else would need to check it in.

Committed.

No regressions on x86_64, and debugging looks the same.

commit 5b974f5ea834aaa456fffd108ad960f7fae0c524
Author: Andi Kleen <ak@linux.intel.com>
Date:   Wed Mar 26 18:45:37 2014 -0400

    Fix dwarf2 unwinding through futex functions.
    
    When profiling programs with lock problems with perf record -g dwarf,
    libunwind can currently not backtrace through the futex and unlock
    functions in pthread. This is because they use out of line sections,
    and those are not correctly described in dwarf2 (I believe needs
    dwarf3 or 4).
    
    This patch first removes the out of line sections. They only save a
    single jump, but cause a lot of pain. Then it converts the now inline
    lock code to use the now standard gas .cfi_* commands.
    
    With these changes libunwind/perf can backtrace through the futex
    functions now.
    
    Longer term it would be likely better to just use C futex() functions
    on x86 like all the other architectures. This would clean the code up
    even more.

Cheers,
Carlos.