RE: [cdt-dev] [DSF] Supporting new GDB commands

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
> Sent: Saturday, June 19, 2010 1:14 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] [DSF] Supporting new GDB commands
> 
> Hi,
> 
> As far as I understand the purpose of using list-features is 
> to have a 
> "universal" command factory for the future GDB versions 

I'm not sure what you mean by that.
Do you mean we could have a single commandFactory that would work
for all GDB version?  I don't see how that would work...

Currently, based on the GDB version, we instantiate the proper
version of the CommandFactory (there is only one version at this time,
but the mechanism is ready).

The difference is that we can figure out GDB's version before starting
the DSF services.   But we can't do that easily for -list-features.

> (of course it 
> will not eliminate the need of having a command factory for MacOS for 
> instance). So there is no need to use different command 
> factories during 
> a debugging session. Which makes #1 the best solution in my 
> opinion. In 
> the ideal world services would try to instantiate sub-services for 
> supported features. Something similar is already done to 
> support memory spaces.

Sub-services seems like an interesting idea.
I haven't looked at how this is done for memory spaces yet...


> 
> Regards,
> Mikhail
> 
> On 19/06/2010 10:19 AM, Marc Khouzam wrote:
> > Hi,
> >
> > we haven't started using -list-features yet (but we really 
> should), so I'm not sure what is
> > the best way to make use of it.  Off the top of my head you could
> >
> > 1- in the MemoryService, the first time you may want to use 
> that command, use -list-features
> > and set a boolean based on the result, then use the proper 
> -data-read-memory* command.
> >
> > This is the simplest solution, but it not the nicest.  It 
> may also go against the CommandFactory
> > model.  Something more elegant would be to either
> >
> > 2- instantiate a new version of the MemoryService for debug 
> sessions that can use the new command
> >
> > 3- instantiate a new version of the CommandFactory for 
> debug sessions that can use the new command
> >
> > I think #3 is the best.
> >
> > The problem is that to do that, you first need to use 
> -list-features, and to do that, you actually have
> > to have instantiated the services (at least the ICommandControl).
> >
> > Instead, you could actually run a 'gdb -ex -list-features' 
> type of thing, before launching the real gdb instance.
> > This is what we do for 'gdb -version'.  Not very nice 
> either, and I'm worried that won't even work
> > because you may have to connect to a remote target before 
> using -list-features, right?
> >
> > So, this seems to point to the fact that we need to be able 
> to change the CommandFactory and/or
> > a Service instance during a debugging session.  That should 
> be doable, but is not entirely trivial because
> > currently we keep pointers to the CommandFactory inside our 
> services.  Instead, we would have to fetch
> > the current version each time, which is not that bad.
> >
> > Makes sense?
> >
> > Marc
> >
> >    
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>