Re: parcelling up struct gdbarch

Andrew Cagney
2001-07-17T10:46:00Z

> I think that's acceptable. The ptrace buffer meets some important
> criteria:
> - it rarely changes, except perhaps to grow (SSE, altivec).
> - We already have to have code to parse it (in order for native gdb
> to work) although this code may not be easily cross-friendly

See other e-mail about signals/events having similar problems.

> On the other hand, we've already GOT a de-facto format, and there are
> debugging stubs out there that use it. This is where I'm confused.

For MIPS we've defacto standards, lots of defacto standards :-)

> What can we do to make it more obvious what format of G packet is being
> sent? My instinct tells me to define the format of the packet, with a
> version number and architecture string, and define a message from
> gdbserver to gdb which contains both arch and version. This would be
> useful for lots of other reasons too. Then if we see a G packet after
> receiving that version notification, we can just pass it off to the
> appropriate handler and be done.

There are two cases:

o GDB talking to one of those old stubs

o GDB talking to a not yet written stub

Even if someone did magic a new stub, GDB would still need to be able to
talk to all the old stubs. Consequently, I'll only look at old stubs.

With that in mind, I think, the G-packet <-> raw register mapping
shouldn't be per gdbarch hard-coded but instead driven by something the
user can specify on the command line. Short term, some sort of
hardwiring might be accepted.

Refering back to that figure:

G-packet registers
|
raw registers
|
cooked registers

If raw registers are given names independant of the user visible cooked
registers then, something as silly as:

0:gpr0,4;1:gpr1,4;4;3:spr0;8;4;...

would even work.

> That same version notification can define a format for the T and P
> packets also (of course gdbserver doesn't even support P packets yet,
> as far as I see).

John S. Kallal submitted a patch: ``[PATCH] Add remote P packet ...''
It needed to be split in two (cleanup VS change) and along with a few
other tweeks.

> Rather than letting ideas continue to bounce around, how's this:
> - add an arch request to GDB and gdbserver. It seems more natural for
> gdbserver to send its architecture and gdb acknowledge if it
> understands; but a qArch would work too.

See the multi-arch white paper. It notes both alternatives. qArch is
probably more inline with other parts of the protocol. I don't think
you need to do this to solve the current problems.

> - Define, for a given gdbarch, how to parse the G/T/P packet register
> numbering.

As I noted above, a given gdbarch might have _several_ G-packet <-> raw
register mappings

Andrew