Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock

[Arun Sharma]

On Sat, Sep 20, 2014 at 8:55 PM, Paul Pluzhnikov <address@hidden> wrote:
> On Sat, Sep 20, 2014 at 7:21 AM, Arun Sharma <address@hidden> wrote:
>
>> If dl_iterate_phdr() returned vDSO, I think libunwind will just work.
>> However, a recent commit linked to:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=16046
>>
>> removed the vdso from user visible API.
>
> I do not believe above statement is correct: vdso is most definitely
> still returned by dl_iterate_phdr (at least for dynamically-linked
> binaries).
>

You're right. I didn't carefully look at the output of the test
program in the bug.

$ ./t1
addr=(nil) name= phdr=0x400040 phnum=9
addr=0x7fff49afe000 name= phdr=0x7fff491fe040 phnum=4
<------------------- vdso (which I missed)
addr=0x7f6628e90000 name=/lib/x86_64-linux-gnu/libc.so.6
phdr=0x7f6628e90040 phnum=10
addr=0x7f6629258000 name=/lib64/ld-linux-x86-64.so.2 phdr=0x7f6629258040 phnum=7

$ ldd t1
linux-vdso.so.1 =>  (0x00007fffe79fe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f80d480b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f80d4bea000)

Is there a way to recognize the vdso from the output of
dl_iterate_phdr (other than name=null?). I'd like UNW_DEBUG_LEVEL to
print something more informative when it finds the vdso.

 -Arun