Re: parcelling up struct gdbarch

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

On Thu, Jul 19, 2001 at 01:52:58AM -0400, Andrew Cagney wrote:
> > 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.

Well, the example I was considering here was something like SSE
registers or Altivec registers which may or may not be available - you
can safely increase the size of the user struct, and you can add
subrequests like PTRACE_GETFPXREGS (or whatever it's called).

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

Well, implementation-wise and protocol-wise I'll need the same things
to do it hard-wired before I can do it flexibly, so I'm implementing
that structure now (I'm mostly done it, actually - I'm testing it for
mips32 now, and if it works I'll post it in the morning).

Having flexible packet specs would remove a couple of trivial functions
that I wrote, but I'd prefer to tackle that idea after the remainder of
the issues have been dealt with.

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