This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Problem with -stack-list-frames
- From: Dmitry Smirnov <divis1969 at mail dot ru>
- To: gdb at sourceware dot org
- Date: Wed, 11 Feb 2009 20:55:01 +0300
- Subject: Problem with -stack-list-frames
- Reply-to: Dmitry Smirnov <divis1969 at mail dot ru>
Hi,
I was using gdb-6.8.50.20080630 for a while in the following configuration:
- Eclipse CDT as a front end,
- gdb-6.8.50.20080630 as ARM debugger connected to skyeye simulator
- skyeye simulator as a remote target (server)
It was working fine till I had tried to swicth to another (modern) way in CDT debug configuration (called DSF).
With the guys that support this new feature, we found that gdb does not respond correctly to -stack-list-frames command.
Here is the output, I got from gdb (plus few more commands):
info threads
* 1 Thread <main> tmc_init () at qct\services\tmc\tmc.c:11541
warning: RMT ERROR : failed to get remote thread list.
-stack-list-frames
bt
#0 tmc_init () at qct\services\tmc\tmc.c:11541
#1 0x00c1d4c6 in tmc_task (ignored=<value optimized out>)
at qct\services\tmc\tmc.c:12350
#2 0x00eee43e in rex_thread_init (entrypoint=0xc1d4a9 <tmc_task+1>)
at qct\services\rexl4\rexl4.c:174
#3 0x00f3e0c8 in __thread_stub ()
#4 0x00f3e0c8 in __thread_stub ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
As you can see, info threads and bt works as expected.
Don't you know what could be the reason for such a silence of -stack-list-frames?
Could you please tell where can start debugging GDB to catch the root cause?
BTW, in case you would find it usefull to read the CDT maillist topic, see http://dev.eclipse.org/mhonarc/lists/cdt-
dev/msg14275.html
Dmitry