[
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