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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

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. So, using the command factory pattern as implemented in
CommandFactory interface does not seem to make a whole lot of sense to me. It's not like you
can have 'createMIDataReadMemory' method that creates slightly different commands in different
implementations. Those are two totally different commands, and MemoryService should execute
different code paths depending on which command is in use.

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? 


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

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.

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

Thanks,

-- 
Vladimir Prus
CodeSourcery
vladimir@xxxxxxxxxxxxxxxx
(650) 331-3385 x722