Re: parcelling up struct gdbarch

[Andrew Cagney <ac131313 at cygnus dot com>]

> 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.


Careful.  That code is now interpreted in a different light.

GDBarch sets up a mapping between an user-visible or cooked registers 
and the raw register cache.  Which registers are ``available'' depends 
on several things:

	o	the cooked registers visible to
		the user

	o	the raw registers stored in the register cache

	o	the register values supplied by the
		target (or gdbserver).


> 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.


Don't forget you need to bump the syscall number as part of that new 
interface.


> 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.


Either that or a formal specification of what a G packet should contain 
and then stick too it.


> 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?


Hmm


> (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.)


I think there are two paths.  One has a formalized G packet layout the 
other has  total flexability.  If GDB is going to try to accept multiple 
different packet layouts then it will surely miss one.  In that case, 
why not assume it will miss one and give the user the flexability to 
specify a custom packet spec.  The set of named packets could just be 
pre-defined specifications.  A set of hard-wired packet specs would be a 
compromise.

	Andrew