Re: parcelling up struct gdbarch

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Tue, Jul 17, 2001 at 02:36:53PM -0400, Andrew Cagney wrote:
> > I don't understand why you say that we would need more than one
> > G-packet format per gdbarch.  Why?  Compatibility with different stubs?
> 
> 
> To remove the need to recompile GDB every time someone wants to get GDB 
> to talk to a stub.  Instead of having to incorporate C code for each and 
> every MIPS g-packet format, a simple generic table.  If the user finds 
> their packet isn't included then just specify its layout on using the CLI.

> Why should the entire register cache get re-structured everytime someone 
> tweeks the architecture.  It is what GDB currently does, I don't think 
> it is right.

I'm looking right now at rs6000-tdep.c.  When we need a gdbarch for a
PPC binary, we call rs6000_gdbarch_init, which builds the architecture. 
What registers are available depends on what registers the target
architecture actually has.

At the same time, what registers gdbserver can provide are strictly
limited - in the same way that what registers infptrace can provide are
also strictly limited.  In this case, to the bulk of the GPRs, the
FPRs, and eventually (if no one beats me to it, I'll be adding kernel
support for...) the Altivec registers if we're on a processor that has
them.

No matter what architecture is set, if we're debugging userland Linux
applications, they see the same things.  Linux userland is, for all
intents and purposes that I can see, a gdbarch itself - two if you
break it up w.r.t. whether Altivec is available or not.  It determines
calling conventions and available registers.  This could, of course,
change.  It's not unreasonable to hypothesize ptrace returning
different registers depending on what processor is actually in use.

Somehow, we need to get GDB and gdbserver to agree on what registers
exist and what will be sent in a register info packet.  This will, as
far as I'm concerned, require some sort of protocol addition.  As I see
it:
  - gdbserver is the authority on what registers are available.
  - gdb must be prepared to give meaning to all of those registers
    (even if "meaning" == "none").
We can tie it to the gdbarch, but that seems like a bad idea,
especially given the flexibility with which gdbarches seem to be
generated.


So, in my N'th consecutive suggestion: is it reasonable to assign a
name to each register packet format, document them by name, and allow
GDB to send a query for the format which gdbserver will use?

(for what it's worth, which is probably not much, I like this solution
for this particular problem better than anything else I've come up with
or heard so far, and it sounds like we were both going in this general
direction.)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer