[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-debug-dev] Residual CDT hacks
|
Embedded applications can also print to something akin to stdout/stderr
which is routed in hardware via the GDB server protocol, which CDT puts
into the bitbucket.
Is this is similar to the "monitor" problem
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=119370)?
BTW, there have been informal discussions to implement a special
gdb-oriented launch type that will cover local and remote debugging. This
will allow us to get rid of all other gdb launch configuration types. I have
looked at the James P. Lynch's tutorial, but I 'll need more information.
----- Original Message -----
From: "Øyvind Harboe" <oyvind.harboe@xxxxxxxxx>
To: <cdt-debug-dev@xxxxxxxxxxx>
Sent: Tuesday, March 14, 2006 12:59 PM
Subject: [cdt-debug-dev] Residual CDT hacks
I can not promise I'll do this all for 3.1 (being busy working on some
internal issues) but I'll try.
Thanks!
BTW, what do you mean by "Recover some lost GDB output"? Is this
related to
those mi commands that are not compatible with CLI.
It has been so long since I did this that I honestly don't recall.
However, e.g. "load" produces some output that is swallowed by CDT by
default.
Embedded applications can also print to something akin to stdout/stderr
which is routed in hardware via the GDB server protocol, which CDT puts
into the bitbucket.
--
Øyvind Harboe
http://www.zylin.com
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev