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

["Alain Magloire" <alain@xxxxxxx>]

> 
> I believe that for embedded purposes the GDB console is more important
> than for debugging PC applications.
> 
> The GDB console is also useful as a way of working around various minor
> problems in CDT.
> 
> In light of this, I'd like to request that this PR is feature-creeped
> into 2.1 (or 2.1.x, if there is such a thing):
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D78382
> 
> Example of a PR where the GDB console  could have been used as a
> workaround:
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D27892
> 
> 
> Although this posting is specifically about the GDB console, it is=20
> bound to touch on the general issue of when and what to "release". On
> that issue, IMHO, quality and base features are more important than the
> schedule.=20
> 
> (My embedded CDT plugin is lready running a slightly hacked up version
> of CDT, so I'm considering hacking this in as well.)
> 

Looking at:
	 https://bugs.eclipse.org/bugs/show_bug.cgi?id=78382

I'm not sure of what you want here. You typed in the GDB console
  monitor
  load
and the output comes out to the console ... what is the problem ?
Are you more talking about more UI integration?  and in what way?

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.

- 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.

Maybe the solution is to ... remove the gdb console 8-)
and replace it by a "simulacre" that will accept the common gdb commands.