Re: parcelling up struct gdbarch

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

On Fri, Jul 13, 2001 at 03:35:27PM -0400, Andrew Cagney wrote:
> > For the benefit of gdbserver, as discussed, I'd like to break the struct
> > into two pieces - call them, hypothetically, gdbarch and gdbarch_native.
> > Things which gdbserver should be able to share, like PC_REGNUM and other
> > things relating to register layout, or like CANNOT_FETCH_REGISTER, etc.,
> > would go in the smaller native struct.  They could be fetched from a (split
> > off from the existing) target specific file, or temporarily added in the
> > appropriate low-<arch>.c.
> > 
> > Does this sound reasonable?
> 
> 
> To me this seems artificial.  I can understand a split along the lines 
> of ISA and ABI but not one justified on the grounds of what gdb-server 
> needs.  That feels like putting the cart before the horse.
> 
> Could I strongly encourage you to at least try to build a bloated GDB 
> server so that you (and everyone else) know what the real problems are. 
>   I think you will find that the bloat caused by *-tdep.c will be in the 
> noise compared to the other things that are draged in.
> 
> Could I also encourage you to examine exactly what information you do 
> need from gdbarch.  The big ones that that I know of are 
> REGISTER_RAW_SIZE() and REGISTER_BYTE().  The way that they are used to 
> construct/destruct a G packet are simply wrong.

Indeed.  The current errors on one typical target - powerpc-linux -
are:

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'

There's a couple of culprits:
low-linux.c - fetch_register, store_inferior_registers, and the
allocation of a block large enough to hold all the registers.

server.c - references to REGISTER_BYTES

remote-utils.c - putpkt, outreg, and of course prepare_resume_reply
(which does things like #ifdef NPC_REGNUM, no longer valid at all).


This is ignoring the few things normally in the tdep file, which in
deference to current practice I've just been putting in
machine-dependent sections of low-linux.c.

> To repeat an earlier point, I think there needs to be something outside 
> of gdbarch that specifie what a G packet layout is and how that G packet 
> is mapped to/from a raw-regnum or a native register.  Remember, the G 
> packet is part of an unchanging and public interface (I'll resist the 
> temptation to suggest specifying it in ASN.1 :-).

Thank you :)  The question then becomes, how do we specify this
information in a way that gdbserver and gdb can both make use of it. 
A given GDB may need to support more than one such format, while a
given gdbserver (at this time, at least) only wants to know one.

Here we're back to the original question of whether to bring gdbserver
and gdb closer together or farther apart.  As a more useful test of things
referenced in gdbserver, I replaced the inclusion of "defs.h" in
server.h with a much smaller set of includes.  No nm.h; no xm.h; no
tm.h; no gdbarch.h.  The only things missing were:

  REGISTER_BYTES, KERNEL_U_ADDR, PC_REGNUM, SP_REGNUM, FP_REGNUM

So I could eliminate use of these macros in gdbserver, by documenting
that the low-* files need to provide routines to do the tasks in
remote-utils.c that referenced the macros, and documenting that the
low-* files need to export the size of the register cache or make
server.c unaware of it (that's also a G/g-packet related use, and
pretty easily eliminatable).

Doing it this way enforces clear boundaries, with all the advantages
that implies.  It also increases, to some extent, code duplication.
My position on that has changed a bit as I've been going over the code;
I've come to think that the advantage of boundaries may in fact
outweigh the disadvantages of duplication, especially since we can cut
the duplication down a fair bit by simpling going over the code
(low-linux is in need of some cleanup).

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