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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@xxxxxxxxxxxxxxxx] 
> Sent: Monday, June 21, 2010 6:01 AM
> To: cdt-dev@xxxxxxxxxxx
> Cc: Marc Khouzam
> Subject: Re: [cdt-dev] [DSF] Supporting new GDB commands
> 
> On Saturday 19 June 2010 18:19:58 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.
> 
> I am not sure I follow #3. The new command is fairly 
> different to the old one both in options it
> accepts and in output it produces. 

Yes, if the command is different in input/output, you can't
use the CommandFactory.  It wasn't clear from your email
if the new command was similar or different in that respect.

> I am also unsure why you suggest new versio nof 
> MemoryService. While the logic has to be different,
> it's logic for reading memory block, so it's relatively 
> localized. Why cannot existing MemoryService
> consult a boolean flag somewhere, and act accordingly? 

I wasn't sure if you wanted to do this in DSF-GDB or in
your own product.  For your own product, you'd have to 
have your own version of the MemoryService.

For DSF-GDB, we could enhance the current MemoryService
depending on the complexity of the change.

> > I'm worried that won't even work
> > because you may have to connect to a remote target before 
> > using -list-features, right?
> 
> I don't think it's required. For -list-target-features -- 
> yes, you better have your real target in place.
> -list-features outputs a fixed list.

And it can be run just as validly before the inferior starts?
Then we could use
gdb -ex "interpreter-exec mi -list-features" -ex quit
just like we use
gdb --version
to allow us to choose the proper services versions (see GdbDebugServicesFactory)

I'm not very fond of that solution though.


> > 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.
> 
> Does that mean that any code that manages to store a 
> reference to CommandFactory is potentially buggy?

If the CommandFactory can change at any time, yes, that would
be a new requirement and therefore existing code would pose a problem.
Same for services, if they are to be changed dynamically.

> Would it be better -- assuming changing command factory is 
> the right strategy -- to use an intermediate
> never-changing CommandFactory that forwards to a real 
> implementation that can be replaced at runtime?

Yes, it sounds like a Proxy would be a simpler way to deal
with this. 

But it looks like the CommandFactory won't work in your case.
Changing the service may be the way to go.

Mikhail had opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=271156
to add the use of -list-features.  You can try things out as part of 
that bug, or you can open a new bug for your specific problem, and try
a solution there.

Marc