On Sat, Sep 20, 2014 at 8:55 PM, Paul Pluzhnikov <[email protected]> wrote: > On Sat, Sep 20, 2014 at 7:21 AM, Arun Sharma <[email protected]> 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 _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
