Re: [cdt-debug-dev] 2.1.x GDB console feature creep request

["Alain Magloire" <alain@xxxxxxx>]

Bonjour

> Ah, we have a bit of confusion here! :-)
> 
> No. The output of "load", "monitor", etc. does not show in the CDT GDB
> console.
> 
> I copy & pasted the expected output from an Insight session.
> 
> We can see in the CDT trace (org.eclipse.cdt.debug.mi.core) that CDT
> receives the output from these commands.
> 

Ha! yes.
The '@' stream is consider to be the "target-stream-output" in MI parlance
This output is not shown to the user .. if we push it to the console with
this be satisfactory ?

FYI, MI as 3 different stream:
console-stream-output
target-stream-output
log-stream-output

The console-stream-output is what is push in the GDB console.
It is the textual response to a CLI command.
See MI protocol document for more.

> > Are you more talking about more UI integration?  and in what way?
> 
> First CDT should publicly declare that they endorse & support the GDB
> console as an execellent compliment to a GUI based debugger frontend.=20
> 
> Stop beating it up.=20
> 
> It may be some time before all issues are worked out, because this is a
> difficult, large, but important, feature. Changes to GDB will also be
> required before all this is over. CDT & GDB are here for the laung haul.
> 

Agreed.

> Some features:
> 
> - <tab> (symbol completion)
> - "(gdb)" prompt to make it more familiar for GDB experienced engineers
> - remove output from CDT's own GDB traffic(Insight has communication
> w/the GDB server that there is no evidence of in its GDB console).
> - better startup support, e.g.
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D79875
> 

Noted, but you should advocate this in the Eclipse/Debug mailing list too.
If the Platform/Debug console could provide support for keybindings etc ..
That would be of great help 8-)

> > Note:
> > - CDT/Debug/GDB uses MI as the protocol of choice,
> >   the fact that the implementation sometimes(many times)
> >   falls back to CLI commands is unfortunate and we would like
> >   to remove it in the future.
> >=20
> > - Synchronizing the user console with the
> >   internal implementation is not easy, for example the introduction
> >   of "-interpreter-exec" command altough made things a little easier
> >   to implement the user console did not help in syncing the states.
> 
> Difficult is fine.
> 
> All the more value of a fully functional CDT.
> 
> Thats why top engineers are working on the problem!
> 
> :-)
> 

Flattery is a motivator but ... $$$ is a more powerfull one 8-)
But seriously it takes some iterations to get things right.
 
> > Maybe the solution is to ... remove the gdb console 8-)
> 
> Ne touchez pas mon pot!=20
> 

8-), noted.

> > and replace it by a "simulacre" that will accept the common gdb commands.
> 
> Thats what Insight does, right?
> 

Not exactly, Insight is __linked__ with gdb so basically insight __is__ gdb.
The rationale to not link with gdb:
 - license restrictions(libgdb.a)
 - and we want a clear separation, so if gdb goes down, Eclipse is not affected.

> 
> Before anyone asks :-), I'm using CDT more and more for deeply embedded
> debugging...
> 

That's what we wanna hear, keep those patches coming.
But as Andrew(GDB maintainer) mentionned; at one point we will have to work
on gdb source code, we can not keep pushing those hacks.
Most of the workarounds in CDT/Debug/MI should not have be remove and
we should have a proper fix in gdb ... sigh ... but lets not get ahead
of ourselves .. it takes times for things to mature.

--
alain