Re: parcelling up struct gdbarch

[Andrew Cagney <ac131313@cygnus.com>]

> 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