RE: Memory-mapped peripheral registers, remote protocol and memory maps

["Jon Beniston" <jon at beniston dot com>]

Hi Paul,

> > Yes, this is fine from the command line, but ideally I would like
something
> that works when GDB is being driven by a GUI such as Eclipse, which may
not
> necessarily know the correct size to use. It does work in some cases, but
not
> all (i.e. when dumping memory).
> 
> If so, that would be the GUI's issue.  If GDB can be told what to do --
which
> appears to be the case -- then it's up to whoever does the telling to tell
> correctly.  If GDB can do it but you ask it the wrong thing, it will obey
and do
> the wrong thing.  So don't do that.

It doesn't seem like the right approach to me to require each GDB GUI (or
user) to have detailed knowledge of the target h/w. Wouldn't it be better if
this info came from the target, in the same way the memory map or target
description does?  GDB already has the hooks to deal with this (via the mem
command), it's just a case of how to best get that info and then actually
make use of it. 

I don't think it would make sense to propagate this target information to
the GUI to require it to only generate correct commands, otherwise you are
requiring the problem to be solved in each GUI, rather than just in one
place in GDB.

> What's not clear to me is whether there is a *guarantee* that 
> certain UI requests will produce certain "m" packets.  Clearly 
> there are a bunch of things that fall out of the current implementation,
>  but if somehow the implementation were to change and,
>  say, that "p" command above is split into two m packets, what then?  

Well, I would expect that any command should respect the attributes set via
the 'mem' command, if it doesn't, it's a bug, if it can't, it should
generate an error message?

Cheers,
Jon