Re: Multi-arch question

[Andrew Cagney <ac131313 at cygnus dot com>]

David Smith wrote:
> 
> I need a philosophical question answered.  Let's say I'm writing new
> support for processor "foo" for GDB.  I'm going to use the architecture
> vector exclusively, so that the only thing that config/foo/tm-foo.h has
> in it is:
> 
> #define GDB_MULTI_ARCH 1
> 
> (or should that be 2?)

Neither.  Pure multi-arch targets don't need a tm.h file. Have a look at
the m68hc11.

> So, my function foo_gdbarch_init() (in foo-tdep.c) calls all the
> set_gdbarch_* functions to fill in the architecture vector.
> 
> In one of the functions in foo-tdep.c, I need to know the current value
> of the PC.  So, which of the following to I do?
> 
> 1) Call the TARGET_READ_PC macro, which really calls gdbarch_read_pc(),
> which ends up calling my foo_read_pc().  (The normal thing to do.)
> 
> 2) Call foo_read_pc() directly.  (Since I'm inside foo-tdep.c, I could
> cut to the chase and call foo_read_pc() directly.)
> 
> Is there a standard here?  Does it matter?

Most likely going through the architecture vector is correct.

*-tdep.c can be broken down into an ABI and an ISA.  The ISA
(instruction set architecture) describes things like the registers and
memory.  The ABI (application binary interface) describes things like
stack frames, calling conventions, ...

ABI code should use the GDBARCH vector to get at ISA information.  For
instance the info registers command should not be pokeing around in the
register buffer directly.  Instead it should be using generic
register/frame operations to obtain the registers.  You'll quickly
notice that most info-regs commands don't actually do this (which is why
they are broken :-/).

	Andrew