identifying shared libraries in gdb?

identifying shared libraries in gdb?

[Roy Smith]

We've got a core file from a customer and suspect that the customer may
not have the right set of shared libraries installed.  On solaris dbx, we
would use "proc -map" to see the elf checksums of each loaded library and
run "elfdump -k" on the .so's that should be there and see if the
checksums match.  Is the a way to do the equivalent in gdb on linux?

Re: identifying shared libraries in gdb?

[Sergio Durigan Junior]

On Wednesday 14 April 2010 18:42:04, Roy Smith wrote:
> We've got a core file from a customer and suspect that the customer may
> not have the right set of shared libraries installed.  On solaris dbx, we
> would use "proc -map" to see the elf checksums of each loaded library and
> run "elfdump -k" on the .so's that should be there and see if the
> checksums match.  Is the a way to do the equivalent in gdb on linux?

Hello Roy,

If I understood your question correctly:  I posted a patch more than a year 
ago that may address what you want:

http://sourceware.org/ml/gdb-patches/2008-12/msg00322.html

Unfortunately, I never touched this patch again (big shame on me!) and it 
never got accepted because I "abandoned" it.  Anyway, I don't know how hard it 
will be to rebase it on the current HEAD, but you may want to try it.

I intend to work on this patch again soon, but please let me know if you have 
any trouble with it.

Thanks,

-- 
Sergio

Re: identifying shared libraries in gdb?

[Jan Kratochvil]

On Wed, 14 Apr 2010 23:42:04 +0200, Roy Smith wrote:
> We've got a core file from a customer and suspect that the customer may
> not have the right set of shared libraries installed.  On solaris dbx, we
> would use "proc -map" to see the elf checksums of each loaded library and
> run "elfdump -k" on the .so's that should be there and see if the
> checksums match.  Is the a way to do the equivalent in gdb on linux?

I am aware only on build-id enabled systems (recent Fedoras, unaware of
others):
$ eu-unstrip -n -p `pidof sleep`
0x400000+0x206000 449e4ead03ed87773ded7ee2da232e663935f50f@0x40024c /bin/sleep /usr/lib/debug/bin/sleep.debug /bin/sleep
0x3d28400000+0x21f000 18c05f9f21450f2d5d8c61b2bfa06d55cdd0f67c@0x3d284001d8 /lib64/ld-2.11.1.so /usr/lib/debug/lib64/ld-2.11.1.so.debug /lib64/ld-2.11.1.so
0x3d28c00000+0x374000 0625835c70e0a883fc4889b45a8fcd66536ed29b@0x3d28c00280 /lib64/libc-2.11.1.so /usr/lib/debug/lib64/libc-2.11.1.so.debug /lib64/libc-2.11.1.so
0x3d29800000+0x218000 3ba0bd0cc7da6d2fa0cb7df46f74f2deefeb1911@0x3d29800248 /lib64/libpthread-2.11.1.so /usr/lib/debug/lib64/libpthread-2.11.1.so.debug /lib64/libpthread-2.11.1.so
0x3d2a000000+0x208000 f548dbf46ffc75059aee750297c6ab67c6b95d20@0x3d2a000248 /lib64/librt-2.11.1.so /usr/lib/debug/lib64/librt-2.11.1.so.debug /lib64/librt-2.11.1.so
0x7ffff5daf000+0x1000 - - - [vdso: 926]

It works the same for:
$ eu-unstrip -n --core=./core.1689 

$ eu-readelf -n /bin/sleep | grep 'Build ID'
...
Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x23c:
  Owner          Data size  Type
  GNU                   20  GNU_BUILD_ID
    Build ID: 449e4ead03ed87773ded7ee2da232e663935f50f
the hash matches as youc an see.

eu-unstrip is "unstrip" and eu-readelf is "readelf" utility from the package
"elfutils".


Regards,
Jan