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

[Jared Cantwell]

I've turned off address space randomization and looked for an IP in
the vdso range.

address@hidden:~/unwindrepro$ ldd a.out
linux-gate.so.1 =>  (0xb7fff000)   <----- vdso range
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7fcf000)
.......

Running with UNW_DEBUG_LEVEL=16 shows the following for the final
failing unw_step call.  It doesn't look like the IP is in the vdso
range, but I could be misreading.  To me though, it looks like the IP
falls into libpthread, which the debug output appears to correctly
show.

 >_ULx86_step: (cursor=0xb7c96930, ip=0xb7fb5ead)
                >get_rs_cache: acquiring lock
              >_ULx86_dwarf_find_proc_info: looking for IP=0xb7fb5eac
               >_ULx86_dwarf_callback: checking , base=0x0)
               >_ULx86_dwarf_callback: checking , base=0xb7fdf000)
               >_ULx86_dwarf_callback: checking
/lib/i386-linux-gnu/libpthread.so.0, base=0xb7fad000)
               >_ULx86_dwarf_callback: found table
`/lib/i386-linux-gnu/libpthread.so.0': segbase=0xb7fbea74, len=684,
gp=0xb7fc4ff4, table_data=0xb7fbea80

Am I reading this properly, or is this actually the vdso problem?

~Jared

On Sat, Sep 20, 2014 at 9:54 AM, Arun Sharma <address@hidden> wrote:
> 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