Problem with GDB/MI -stack-info-depth in multithreaded MIPS program

Problem with GDB/MI -stack-info-depth in multithreaded MIPS program

[Yoni Rabinovitch]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-8859-8-i, Size: 6586 bytes --]

Hi,

I am trying to cross-debug a multithreaded program running on an embedded MIPS 5Kc using 
Eclipse GDB/MI (running on a Red Hat 9.0 PC) and gdbserver.

My environment is as follows:

MIPS kernel based on 2.4.18
gdb :  6.2.1, configured with --host=i686-pc-linux-gnu --target=mips-hardhat-linux --disable-sim --disable-tcl --enable-threads --enable-shared
gdbserver: 6.2.1, configured with --target=mips-linux --enable-threads --enable-shared
gcc : 3.2.3,     }
binutils : 2.13  }   Built using crosstool
glibc: 2.2.5     }

Now, regular (command line) gdb works OK in my environment, with one small problem. When I try
to examine the stack (e.g. "backtrace"), I get something like the following:

(gdb) bt
#0  0x2ad00b84 in nanosleep () from /pub/mips-gnu/lib/libc.so.6
#1  0x2ab4e638 in nanosleep () from /pub/mips-gnu/lib/libpthread.so.0
Cannot access memory at address 0x2c

This is OK (I guess), apart from the "Cannot access memory at address 0x2c".
I have been told that GDB sometimes gets confused by glibc's syscall stubs, and that I don't need
to worry about errors at the end of backtraces.

HOWEVER, it seems that this error causes the GDB/MI -stack-info-depth command to fail, as can 
be seen from the following trace (from Eclipse):

[1,100,086,148,682] (gdb)
[1,100,086,148,683] 440-stack-info-depth
[1,100,086,148,990] &"Cannot access memory at address 0x2c\n"
[1,100,086,148,990] 440^error,msg="Cannot access memory at address 0x2c"
[1,100,086,148,991] (gdb)

This in turn prevents the Eclipse CDT debug session from working properly.
After -stack-info-depth fails, no -stack-list-frames gets issued, and the debugger
more or less hangs.

So, my question is, is there any way I can get -stack-info-depth to succeed, rather
than just throwing the "Cannot access memory..." error ? After all, gdb "backtrace"
works, and provides useful output before the error, so why doesn't -stack-info-depth ?

I have attache3d below more detailed traces of gdb "backtrace" and gdb/mi "-stack-info-depth"
after enabling the gdb debug frame flag.

Thanks in advance for any help !!

Yoni

Output from regular gdb "backtrace" command, after "set debug frame 1"
======================================================================
(gdb) set debug frame 1
(gdb) bt
#0  0x2ad00b84 in nanosleep () from /pub/mips-gnu/lib/libc.so.6
{ get_prev_frame_1 (this_frame=0) -> {level=1,type=NORMAL_FRAME,unwind=0x81e46f4,pc=0x2ab4e638,id={stack=0x30,code=0x2ab4e5d8,!special},func=0x2ab4e5d8} // cached
#1  0x2ab4e638 in nanosleep () from /pub/mips-gnu/lib/libpthread.so.0
{ get_prev_frame_1 (this_frame=1) -> {level=2,type=UNKNOWN_FRAME,unwind=<unknown>,pc=<unknown>,id=<unknown>,func=<unknown>} // cached
{ frame_register_unwind (frame=1,regnum=127(pc),...) Cannot access memory at address 0x2c
(gdb) 



Trace of Eclipse GDB/MI -stack-info-depth command, after "set debug frame 1"
============================================================================
[1,100,086,402,555] 444 set debug frame 1
[1,100,086,402,559] &"set debug frame 1\n"
[1,100,086,402,560] 444^done
[1,100,086,402,560] (gdb)
[1,100,086,405,243] 445-thread-select 4
[1,100,086,405,251] &"{ flush_cached_frames () }\n"
[1,100,086,405,373] &"{ create_sentinel_frame (...) -> {level=-1,type=<unknown type>,unwind=0x822dd9\
4,pc=<unknown>,id={!stack,!code,!special},func=<unknown>} }\n"
[1,100,086,405,374] &"{ get_prev_frame_1 (this_frame=-1) -> {level=0,type=UNKNOWN_FRAME,unwind=<unkn\
own>,pc=<unknown>,id=<unknown>,func=<unknown>} }\n"
[1,100,086,405,375] &"{ frame_register_unwind (frame=-1,regnum=127(pc),...) -> *optimizedp=0 *lvalp=\
2 *addrp=0x1fc *bufferp=[2ad00b84] }\n"
[1,100,086,405,376] &"{ frame_pc_unwind (this_frame=-1) -> 0x2ad00b84 }\n"
[1,100,086,405,376] 445^done,new-thread-id="4",frame={level="0",addr="0x2ad00b84",func="nanosleep",a\
rgs=[],from="/pub/mips-gnu/lib/libc.so.6"}
[1,100,086,405,377] (gdb)
[1,100,086,405,379] 446-stack-info-depth
[1,100,086,405,390] &"{ get_prev_frame_1 (this_frame=0) { get_frame_id (fi=0) {
frame_register_unwin\
d (frame=-1,regnum=90(zero),...) -> *optimizedp=0 *lvalp=2 *addrp=0x168 *bufferp=[00000000] }\n"
[1,100,086,405,434] &"{ frame_func_unwind (fi=-1) -> 0x2ad00b70 }\n"
[1,100,086,405,435] &"-> {stack=0x0,code=0x2ad00b70,!special} }\n"
[1,100,086,405,435] &"{ frame_id_p (l={stack=0x0,code=0x2ad00b70,!special}) -> 1 }\n"
[1,100,086,405,436] &"-> {level=1,type=UNKNOWN_FRAME,unwind=<unknown>,pc=<unknown>,id=<unknown>,func\
=<unknown>} }\n"
[1,100,086,405,437] &"{ frame_register_unwind (frame=0,regnum=127(pc),...) { frame_register_unwind (\
frame=-1,regnum=121(ra),...) -> *optimizedp=0 *lvalp=2 *addrp=0x1e4 *bufferp=[2ab4aff8] }\n"
[1,100,086,405,438] &"-> *optimizedp=0 *lvalp=2 *addrp=0x1e4 *bufferp=[2ab4aff8] }\n"
[1,100,086,405,438] &"{ frame_pc_unwind (this_frame=0) -> 0x2ab4aff8 }\n"
[1,100,086,405,439] &"{ get_prev_frame_1 (this_frame=1) { get_frame_id (fi=1) {
frame_register_unwin\
d (frame=0,regnum=119(sp),...) -> *optimizedp=0 *lvalp=0 *addrp=0x0 *bufferp=[00000000] }\n"
[1,100,086,405,512] &"{ frame_func_unwind (fi=0) -> 0x2ab4adec }\n"
[1,100,086,405,512] &"-> {stack=0x278,code=0x2ab4adec,!special} }\n"
[1,100,086,405,513] &"{ frame_id_p (l={stack=0x278,code=0x2ab4adec,!special}) -> 1 }\n"
[1,100,086,405,514] &"{ frame_id_inner (l={stack=0x278,code=0x2ab4adec,!special},r={stack=0x0,code=0\
x2ad00b70,!special}) -> 0 }\n"
[1,100,086,405,514] &"{ frame_id_eq (l={stack=0x278,code=0x2ab4adec,!special},r={stack=0x0,code=0x2a\
d00b70,!special}) -> 0 }\n"
[1,100,086,405,515] &"-> {level=2,type=UNKNOWN_FRAME,unwind=<unknown>,pc=<unknown>,id=<unknown>,func\
=<unknown>} }\n"
[1,100,086,405,813] &"{ frame_register_unwind (frame=1,regnum=127(pc),...) Cannot access memory at a\
ddress 0x240\n"
[1,100,086,405,813] 446^error,msg="Cannot access memory at address 0x240"
[1,100,086,405,814] (gdb)
[1,100,086,405,817] 446-stack-info-depth
[1,100,086,405,874] &"{ get_prev_frame_1 (this_frame=0) -> {level=1,type=NORMAL_FRAME,unwind=0x81e46\
f4,pc=0x2ab4aff8,id={stack=0x278,code=0x2ab4adec,!special},func=0x2ab4adec} // cached \n"
[1,100,086,405,875] &"{ get_prev_frame_1 (this_frame=1) -> {level=2,type=UNKNOWN_FRAME,unwind=<unkno\
wn>,pc=<unknown>,id=<unknown>,func=<unknown>} // cached \n"
[1,100,086,405,890] &"{ frame_register_unwind (frame=1,regnum=127(pc),...) Cannot access memory at a\
ddress 0x240\n"
[1,100,086,405,891] 446^error,msg="Cannot access memory at address 0x240"
[1,100,086,405,891] (gdb)