[cdt-debug-dev] Removing "stdout/stdin/stderr" console for embedded deve

[Øyvind Harboe <oyvind.harboe@xxxxxxxxx>]

> > I ended up removing this console entirely for my "idle" debug mode. It
> > doesn't make any sense(in its current form) for embedded development.
> > 
> > Embedded CDT debugging is *really* shaping up!=20
> > 
> > http://zylin.com/pipermail/zylin-discuss_zylin.com/2004-October/000048.html
> > 
> > My changes to CDT are basically:
> > 
> > - add CygWin -> Windows path translation in various places.=20
>
> This was ... problematic.

I know :-) I just wanted to see if I figured out what mechanically was
missing.

> Your proposed patch was not apply because it puts
> Cygwin specifics all over the CDT.

I've fixed that in my latest patch. There is a scheme which is intended
to work for Linux as well as Windows or any other platform.

My accumulated changes to CDT are currently a bit messy because it is a
mixture of solving the CygWin + adding idle mode and various other
tweaks.

> > - Add an "idle" debug mode. This allows launching the GDB debugger in
> > "idle" mode. That is before GDB is connected to a target, without
> > specifying an executable, before symbols are loaded, etc. All
> > connection, loading of symboles, etc. is done manually via GDB
> > console(or .gdbinit files). Since a lot of nasty, target specific stuff
> > needs to happen here(e.g. erasing application from flash, writing the
> > new application to flash, reseting the target, etc.) it doesn't make
> > much sense to try to squeeze this into a standard GUI.
> > 
> 
> So if I read you correctly, beside the 3 other launch(s), we have currently in CDT(head)
> 
>   + C/C++ post-mortem debugger
>   + C/C++ attach to local application
>   + C/C++ local application    (*)
> 
>   (*) this one includes the GDBServer.
> 
> You want an idle launch
>   + C/C++ idle debugger (GDB)
> 
> Only starts the debugger and waits idle ... ok.
>
> Although I did not do such launch, I do not see what modifications you
> required to make this possible in your own plugin, it should be straight forward(sic).
> Something I'm missing?

I don't understand this last paragraph.

> - Using .gdbinit
>   Was it not possible to stuff you extra commands in "gdbinit" and use the
>   "C/C++ local aplication" launch ?  Why do you need to start only gdb ?

.gdbinit does not always work. The problem is that I'm using
asynchronous+buggy "monitor" commands and physically fiddling with the
hardware to prepare it for debugging.


-- 
Øyvind Harboe
http://www.zylin.com