[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Couple issues with DSF
|
Hi Dmitry,
> From: Dmitry Smirnov
> Sent: Saturday, February 07, 2009 1:54 PM
>
> So, first, I have a makefile project for Skyeye for Windows. Usually,
> I'm debugging it with ordinal Local Application configuration. It
> works fine.
> I had created a DSF Local Application configuration which has failed
> to debug the program. Here is the error:
>
> Error in final launch sequence
> Failed to execute MI command:
> -gdb-set auto-solib-add off
> Error message from debugger back end:
> No symbol "auto" in current context.
>
> Perhaps, the problem is the version of the GDB. I'm using
> GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
>
> Is DFS expecting some newer?
6.3 is quite old. (auto-solib-add does not exist in that version, I
believe)
I think we support back to 6.6.
Your best bet is to try 6.8. Is that possible?
> Next problem is DSF Remote Application.
> For the ARM program that runs on skyeye (which is particulary ARM
> simulator with remote debugging support) I'm typically using GDB
> Hardware Debugging. It has a lot of options which allows me, for
> instance, halt on connection to remote target. Thus I can start
> debugging even the binary code at start address (like 0xffff0000).
>
> DSF Remote Application does not provide such options. I can specify
> the function name but not the address, for example... Is it possible
> somehow?
What is the syntax you would use in the GDB command line to trigger
a 'halt on connection'? If it is a breakpoint, maybe we can try
changing the "Stop on startup" option in the launch, or to have your
breakpoint already defined before you launch.
If that does not work, then we probably need a new option...
> Another problem is the call stack when I hit the initial breapboint.
> Hardware debugger shows it (almost) correctly but DSF fails with it:
>
> M2000_ZQ DSF [C/C++ Remote Application (Experimental - DSF)]
> m2000.elf
> Thread[1] (Suspended : BREAKPOINT)
> gdb
> m2000.elf
>
> Hardware debugger shows at the same case:
>
> M2000_ZQ HW [GDB Hardware Debugging]
> GDB Hardware Debugger (07.02.09 21:51) (Suspended)
> Thread [1] (Suspended)
> 5 tmc_init()
> qct\services\tmc\tmc.c:11541 0x00c1d1f2
> 4 tmc_task()
> qct\services\tmc\tmc.c:12350 0x00c1d4c6
> 3 rex_thread_init()
> qct\services\rexl4\rexl4.c:174 0x00eee43e
> 2 __thread_stub() 0x00f3e0c8
> 1 __thread_stub() 0x00f3e0c8
> D:\Install\GDB\gdb-6.8.50.20080630\gdb\gdb.exe (07.02.09 21:51)
> C:\p4\views\KSW_M2000_ZQ_DEV_0331\m2000\m2000.elf
> (07.02.09 21:51)
>
> Does it means that DSF is not suitable for such debugging?
Do you have the DSF logs from the console?
If not, then can you try the command
-stack-list-frames
from the eclipse console, once you got to the point where DSF does not
show the stack?
I'm curious to see if GDB gives us back enough data.
Thanks
Marc
