Multi-arch question

[David Smith]

Andrew Cagney wrote:
> 
> 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.

I just did.  I see that there is no tm.h file.

At first I couldn't figure out where GDB_MULTI_ARCH got defined if there
isn't a tm.h file, but now I see it is done with configure magic.  In
configure.tgt, for the m68hc11, "gdb_multi_arch" is set to "yes".  Then
over in configure, if "gdb_multi_arch" is set to "yes", then
GDB_MULTI_ARCH is defined to GDB_MULTI_ARCH_PURE (3).  Very sneaky.

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

-- 
David Smith
dsmith@redhat.com
Red Hat, Inc.
http://www.redhat.com
256.704.9222 (direct)
256.837.3839 (fax)