Re: parcelling up struct gdbarch

Daniel Jacobowitz
2001-07-18T23:22:00Z

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