Re: Available registers as a target property

[Paul Schlie <schlie at comcast dot net>]

> From: Daniel Jacobowitz <drow@false.org>
>> On Sat, May 07, 2005 at 12:53:48AM -0400, Paul Schlie wrote:
>> - actually arm "extensible architecture" is fairly rigid, and arguably
>>   far less "customizable" than those offered by ARC or Tensilica for
>>   example; and is likely best characterized as being extended via
>>   co-processor extensions not an innate extension/customization of the
>>   arm ISA or processor implementation core architecture itself.
> 
> ... which GDB also needs to support.
> 
>>> ARM's approach to this problem was to encapsulate the description
>>> in the module server, which is distributed with the target
>>> configuration.  Anything that wants the configuration can query the
>>> target for it.  That seems a lot more useful to me - rather than
>>> centralizing the registry, distribute it locally to every target it
>>> describes.
>> 
>> - so you propose that GNU tools adopt a reliance on a proprietary vendor
>>   data base "module server" in order to configure tools to support that
>>   vendors proprietary licensed architecture?
> 
> Please limit yourself to constructive comments instead of accusations;
> it's apparent that you aren't familiar with RDI (not surprising, since
> I don't believe the documentation is publicly available), and that you
> haven't really thought about what I'm suggesting.  Hint: all the
> necessary information can be provided by gdbserver, and will be.  Linux
> KGDB stubs also have enough information to provide this data, and
> hopefully will once GDB supports it.  I'm sure some free software
> simulation systems will also.
> 
> We've gotten way off topic at this point.

I don't dispute the necessity to enable a more detailed description of a
target's configuration (as you have pointed out that many multiple variants
may exist). I was just attempting to suggest that such information, as it's
likely useful to multiple tools, may ideally be formalized and accessible in
a more centralized open manor such that for example it may be directly
accessed by GDB, as opposed to relying on a remote target to supply it; as
that seems like a potentially slippery slope, where if that trend continued,
GDB would become not much more than a user/control interface for a "remote"
proprietary debugger, which doesn't seem like a good thing or direction?

(thanks for hearing me out, I just wanted to make the observation.)