I'm not sure whether this properly belongs on the GDB, NPTL or Linux mailing lists.
I have a multi-threaded application which generates a core file.
GDB apparently understands the core file well enough to know that there are two threads involved,
and interpret the state of the one thread (i.e. "backtrace" and "info reg" works fine)
but doesn't seem to be able to determine the register set/stack of the other thread.
(see below for example GDB output)
If I run the application under GDB, I can breakpoint and see the state of all threads without difficulty.
GNU gdb 6.5.0.20060626-cvs
Linux 2.6.13-1.1532_FC4 SMP i686 i686 i386 GNU/Linux
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
libc-2.3.6.so
Is this problem familiar to anyone? Have you any suggestions?
Is there some configuration directive I need to enable?
Can you tell me how to determine whether the core file just doesn't contain the register values for the "other" thread,
or whether GDB doesn't know how to extract them?
Thanks.
Objdump seems to see multiple register sets (if I understand it, although I don't know how to interpret them):
objdump -h core.1853
core.1853: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 note0 00000cf8 00000000 00000000 000004d4 2**0
CONTENTS, READONLY
1 .reg/1864 00000044 00000000 00000000 00000530 2**2 <--- registers for one thread?
CONTENTS
2 .reg 00000044 00000000 00000000 00000530 2**2
CONTENTS
3 .auxv 00000090 00000000 00000000 00000b70 2**2
CONTENTS
4 .reg2/1864 0000006c 00000000 00000000 00000c14 2**2
CONTENTS
5 .reg2 0000006c 00000000 00000000 00000c14 2**2
CONTENTS
6 .reg-xfp/1864 00000200 00000000 00000000 00000c94 2**2
CONTENTS
7 .reg-xfp 00000200 00000000 00000000 00000c94 2**2
CONTENTS
8 .reg/1853 00000044 00000000 00000000 00000ef0 2**2 <--- registers for the other thread?
CONTENTS
9 .reg2/1853 0000006c 00000000 00000000 00000f4c 2**2
CONTENTS
10 .reg-xfp/1853 00000200 00000000 00000000 00000fcc 2**2
CONTENTS
11 load1 00000000 00195000 00000000 00002000 2**12
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 load2 00001000 001b8000 00000000 00002000 2**12
CONTENTS, ALLOC, LOAD, READONLY
13 load3 00001000 001b9000 00000000 00003000 2**12
CONTENTS, ALLOC, LOAD
<etc>
<GDB output follows>:
(gdb) info thread
2 process 1853 0x00000246 in ?? ()
* 1 process 1864 0x0808cda9 in app_mon_handle_get (bname=0x96a6168 "/app/check", bname_parts=0x96a6190, data=""
resp_bindings=0x96a5e38) at layerManager.cc:1924
(gdb) info reg
eax 0x4 4
ecx 0x0 0
edx 0x9672008 157753352
ebx 0x44e 1102
esp 0xb6a1ee90 0xb6a1ee90
ebp 0xb6a1eef8 0xb6a1eef8
esi 0x362 866
edi 0x8234ad1 136530641
eip 0x808cda9 0x808cda9 <app_monhandle_get(char const*, tstr_array const*, void*, bn_binding_array*)+1825>
eflags 0x10202 [ IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0xc010007b -1072693125
fs 0x0 0
gs 0x33 51
(gdb) thread 2
[Switching to thread 2 (process 1853)]#0 0x00000246 in ?? ()
(gdb) info reg
eax 0xc010007b -1072693125
ecx 0x9687f68 157843304
edx 0x2deff4 3010548
ebx 0x40 64
esp 0x0 0x0 <--- presumably invalid?
ebp 0x7b 0x7b
esi 0xbfe36678 -1075616136
edi 0xfffffffc -4
eip 0x246 0x246
eflags 0x7b [ CF #3 AF #5 ZF ]
cs 0x6658 26200
ss 0x0 0
ds 0xa8 168
es 0x7410 29712
fs 0x0 0
gs 0x33 51
(gdb) bt
#0 0x00000246 in ?? ()
Cannot access memory at address 0x0
(gdb)
_______________________________________________ Gdb mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gdb
