This is the mail archive of the
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: Fri, 06 May 2005 20:55:59 -0400
- Subject: Re: Available registers as a target property
> From: Daniel Jacobowitz <email@example.com>
>> On Fri, May 06, 2005 at 06:46:38PM -0400, Paul Schlie wrote:
>>> Daniel Jacobowitz wrote:
>>> Today, the contents of the register cache and the layout of GDB's regnum
>>> space are determined by the gdbarch. There are several hooks for this,
>>> primarily these three:
>>> The gdbarch determines what raw registers are available. But this isn't a
>>> perfect match with what raw registers are _really_ available, because the
>>> gdbarch only has the clues we use to select a gdbarch available: things like
>>> byte order and BFD machine number. At best, those tell us what registers
>>> the binary we're debugging requires. The runtime set of registers we can
>>> see are a property of the target, not of the gdbarch.
>> Might it be more appropriate to enable gdbarch to be extended to enable the
>> more specific description of a particular target component and mode; as
>> opposed to pushing the requirement of a target to provide detailed register
>> etc. information about itself when all that should be necessary should be
>> for it to more specifically identify itself and present mode if any, thereby
>> enabling a correspondingly more precise gdbarch description to be selected
>> as the basis of it's logically visible model?
> Do you have a concrete suggestion? This sounds not fundamentally
> different from what I am doing.
My sense is that the fundamental difference is where the information is
described/contained, and how the choice of which description to use is
conveyed to the GDB. Although I may misunderstand, it seems more consistent
to enable GDB to select which of N register models to assume based upon the
target's identification, than requiring the target to supply a detailed
description of it's own register model; thereby not requiring any otherwise
unnecessary complexity be added to the target's GDB server implementation?
Where if a logical register/memory model description were formalized more
centrally, (possibly within a more detailed BFD for the target architecture)
then it may be more broadly leveraged my multiple tools, i.e. compiler,
simulator, etc. in time, as opposed to being encapsulated in a GDB specific
Have I misunderstood your proposed approach?