Re: parcelling up struct gdbarch

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

On Sat, Jul 14, 2001 at 11:16:32AM -0400, Andrew Cagney wrote:
> > undefined reference to `current_gdbarch'
> > undefined reference to `gdbarch_cannot_store_register'
> > undefined reference to `gdbarch_fp_regnum'
> > undefined reference to `gdbarch_npc_regnum'
> > undefined reference to `gdbarch_pc_regnum'
> > undefined reference to `gdbarch_register_byte'
> > undefined reference to `gdbarch_register_bytes'
> > undefined reference to `gdbarch_register_raw_size'
> > undefined reference to `gdbarch_sp_regnum'
> 
> 
> Live dangerously, try linking against libgdb.a :-)

Just for kicks, I tried it.  One file at a time, since I couldn't get
GNU ld to tell me what it was bringing in (is there an option for that?).

The problem is that gdbarch is all one file.  To resolve it, we have to
bring in gdbarch.o.  That brings in things like
legacy_breakpoint_from_pc, default_memory_insert_breakpoint, etc.  It
also brings in gdb_stdout, which means we need main.o.  It's hopeless.

This is, of course, resolvable.  We could build gdbarch.c as a large
number of separate files (or one file generating multiple objects, like
how libgcc2 is built) into an ar archive, gdbarch.a.  Then this
wouldn't happen.  I don't know if that's a good idea or not; what do
you think?

> >   REGISTER_BYTES, KERNEL_U_ADDR, PC_REGNUM, SP_REGNUM, FP_REGNUM
> 
> 
> REGISTER_BYTES is hard, I'll ignore it for the moment :-)

Such a pity :)  It's the one that really bugs me.

> KERNEL_U_ADDR lives in nm.h so that one is probably ok.
> 
> As for PC_REGNUM, NPC_REGNUM, ... SP_REGNUM and FP_REGNUM, I think we 
> need to study a little history.

> While it's taken 15 years to figure out, I think this is a register 
> model that works.  As far as core GDB is concerned PC_REGNUM, FP_REGNUM, 
> SP_REGNUM et.al. are all cooked registers.  While for many targets, 
> RAW_FP_REGNUM == COOKED_FP_REGNUM, might be true, they are separate.

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

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.

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.

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.

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