This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: pthread_t ids of threads not showed by "thread info"
On Monday 2010-04-26 11:03:57 +0200, Jan Kratochvil wrote:
> On Mon, 26 Apr 2010 10:38:09 +0200, Stefano Sabatini wrote:
> > $ cd /usr/lib/debug/lib
> > $ cd
> > $ nm -S libpthread-2.10.2.so | grep __stack_user
> > 00017160 00000008 b __GI___stack_user
> > 00017160 00000008 b __stack_user
> > $ nm -S libpthread-2.10.2.so | grep stack_used
> > 0001511c 00000008 d stack_used
>
> You should have DWARFs symbols. The ELF symbols are not enough for structures
> derefencing.
>
> readelf -wi /usr/lib/debug/lib64/libpthread.so.0.debug
> [ formatted a bit ]
> <1><9304>: Abbrev Number: 111 (DW_TAG_variable)
> <9305> DW_AT_name : (indirect string, offset: 0x300b): __stack_user
> <930f> DW_AT_type : <0x461b>
> <9313> DW_AT_external : 1
> <9314> DW_AT_location : 9 byte block: 3 80 b2 21 0 0 0 0 0 (DW_OP_addr: 21b280)
> <1><461b>: Abbrev Number: 3 (DW_TAG_typedef)
> <461c> DW_AT_name : (indirect string, offset: 0x7f8): list_t
> <4622> DW_AT_type : <0x45f0>
> <1><45f0>: Abbrev Number: 14 (DW_TAG_structure_type)
> <45f1> DW_AT_name : (indirect string, offset: 0x2469): list_head
> <45f5> DW_AT_byte_size : 16
> <2><45fc>: Abbrev Number: 11 (DW_TAG_member)
> <45fd> DW_AT_name : (indirect string, offset: 0x169d): next
> <4603> DW_AT_type : <0x4615>
> <4607> DW_AT_data_member_location: 0
> <2><4608>: Abbrev Number: 11 (DW_TAG_member)
> <4609> DW_AT_name : (indirect string, offset: 0x1303): prev
> <460f> DW_AT_type : <0x4615>
> <4613> DW_AT_data_member_location: 8
>
> Anyway these symbols are not required for the right way of traversing this
> list. For that purpose (as being used for native non-core `info threads') GDB
> just calls functions provided by /lib64/libthread_db.so.1 . You can check glibc
> sources for nptl_db/td_ta_thr_iter.c . nptl_db uses simple ELF symbols not
> requiring the debuginfo files, like this one:
> $ gdb -q -ex 'p *(int *)_thread_db_pthread_list' -ex q /lib64/libpthread.so.0
> $1 = 128
>
>
> > I'm currently stucked with this, I really cannot say if it is a
> > problem with what I'm doing or with some debian specific issue.
>
> If Debian GDB cannot find the symbols guessing Debian probably has more light
> (smaller) debug info packages.
Can you suggest a command I can use to check this?
Thanks, regards.