Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-debug-dev] RE: cdt-debug-dev digest, Vol 1 #128 - 1 msg

> Øyvind, may I ask:
> 
>   - Why did you select "GDB debugger" rather than "GDB Cygwin 
> debugger"?

I tried both and I could only get "GDB debugger" to work.

(Note that I don't know how to do this when attaching to
a running target via JTAG.)

The problem with CDT, GDB and embedded development is that
CDT is being too helpful. 

"GDB debugger" is the least intrusive. It is the closest to
letting me write my own .gdbinit and not having CDT trying
to issue load/symbol/run/attach commands.

This is roughly what happens:

- CDT launches my app with the following commandline:

  arm-elf-gdb myfirmware.elf
   
- My own .gdbinit "GDB debugger" executes and uploads the app
via Redboot
  set baudrate 38400
  load XXX

- CDT issues a "run". I'd prefer doing this in .gdbinit myself,
and thus getting more manual control over the debug launch 
procedure. Attaching to a running target using a JTAG debugger
would be a breeze then.
- I break in "main", or whereever I have breakpoints.

>   - Which version of GDB are you using? 5.2.1? 5.3?

Whatever ships with the latest eCos(arm-elf-gdb). I'm at home and
can't check easily.

>   - Are there any other settings in the Debug dialog which 
> you found to be critical?

Yes. This incatation is crucial:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=39638

Vote for having this one fixed :-)

> It would be helpful to observe the sequence of GDB/MI calls 
> made by CDT. Is 
> there a way to view or generate a log of these calls?

Yes, but I can't find the incatations here @ home.

It involves using the -debug option to eclipse.exe and 
creating a .options file.

I think:

eclipse -debug=.options

echo >.options org.eclipse.cdt.debug.mi.core/debug=true


Øyvind



Back to the top