Re: parcelling up struct gdbarch

Andrew Cagney
2001-07-16T12:04:00Z

> legacy_breakpoint_from_pc, default_memory_insert_breakpoint, etc. It
> also brings in gdb_stdout, which means we need main.o. It's hopeless.

If GDBserver is going to be come more tightly integrated into GDB then
it is going to need to pick up some baggage like ui-file.

>> REGISTER_BYTES is hard, I'll ignore it for the moment :-)
>
>
> Such a pity :) It's the one that really bugs me.

It is just a symptom of the below.

>> The gdbserver code that refers to those macros has, has a result of the
>> above revalation, become wrong. The nat code, in general, should refer
>> to nat, raw or G register numbering and not cooked registers. When it
>> comes to the registers to pass back with the T packet, I think it should
>> be given an explicit list.
>
>
> It doesn't refer to those register numbers when generating a G packet
> at all. It just passes the entire buffer. The only issue in creation
> of G packets is REGISTER_BYTES.

Hmm, by ``G packet registers'' I'm refering to how registers are laid
out for a G packet. When the stub creates a T packet that includes
expedited registers, those registers should be identified using their
G-packet numbering.

> It's the T packet that uses them, currently. outreg() sends
> regno:value pairs; regno is a cooked regno. This is the only use of
> REGISTER_BYTE or REGISTER_RAW_SIZE outside of a low-* file.

And it's wrong.

Per other e-mail, gdbserver can have either:

o *-nat.c map system registers onto
raw register and then gdbserver
map raw registers onto G-registers

o *-nat.c map system registers onto
G-registers directly (when compiled
for GDBSERVER, say).

The thing the *-nat and GDB server code shouldn't be doing is trying to
map registers onto internal-to-GDB cooked registers. (Keep in mind that
the existing code base largely doesn't follow this :-( ).

Regardless, remote.c then has to map the incomming G-register onto the
raw registers (as stored in regcache).

> What would you say to providing this list in the form of (cooked regno,
> raw offset, raw size) in the nm.h file? It's very fragile, but without
> protocol changes it's the best we can do right now.

No, something completly outside of *.h that defines the G-packet layout
(and possibly the register cache) and how *-nat.c should map registers
onto it.

> I'm willing to do all sorts of intrusive things to gdbserver to work
> around this for now; as I've said, that gdbserver built for two of the
> targets I tried appears to be almost accidental. I've no qualms about
> breaking it on any number of other targets, if the fixes are cleaner
> than the current state.

This won't (famous last words :-) break any targets and will help the
task of multi-arching the MIPS.

Try building a few different MIPS targets and compare how the G-packet
(unfortunatly aka raw register buffer) is structured for each - (almost)
every single MIPS target has a different G-packet structure and they are
not upward/downward compatible.

Andrew