This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Available registers as a target property
- From: Paul Schlie <schlie at comcast dot net>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: <gdb at sourceware dot org>
- Date: Sat, 07 May 2005 11:19:03 -0400
- Subject: Re: Available registers as a target property
> 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.)