Re: [PATCH RFC] Make GNU/Linux/PPC port work again

[Kevin Buettner <kevinb at cygnus dot com>]

On Jul 19,  5:11pm, Michael Snyder wrote:
> > > >         * ppc-tdep.h: New file.
> > >
> > > What kind of stuff is in this header file,
> > > that could not go into one or more of the
> > > tm.h files?
> > 
> > What you suggest would work.
> > 
> > I was attempting to limit the visibility of the defines that appear
> > in ppc-tdep.h to just a handful of files and unfortunately, the
> > tm.h file is included by just about everybody.
> > 
> > In particular, I was concerned about the following...
> > 
> > +/* Some important register numbers. */
> > +
> > +#define        GP0_REGNUM 0            /* GPR register 0 */
> > +#define        TOC_REGNUM 2            /* TOC register */
> > +#define PS_REGNUM 65           /* Processor (or machine) status (%msr) */
> > +#define        CR_REGNUM 66            /* Condition register */
> > +#define        LR_REGNUM 67            /* Link register */
> > +#define        CTR_REGNUM 68           /* Count register */
> > +#define        XER_REGNUM 69           /* Integer exception register */
> > +#define        MQ_REGNUM 70            /* Multiply/Divide extension register */
> > 
> > In order to feel comfortable with putting these in a common tm-*.h file,
> > I'd want to prefix the names with PPC_ or somesuch.
> 
> 
> No...
> Every tm.h file that I'm familiar with contains defines
> such as these.  Or at least it did pre-multi-arch.
> Is the PPC multi-arched?  If it is, maybe they need
> to go into the gdbarch struct.  If not, they seem to
> belong in the tm.h file.

Yeah.  PPC is multi-arched (just recently, thanks to Nick).  Prior to
being multi-arched there was a single tm.h file that contained these
constants.  (And all of the other tm.h files included this one and
would override definitions as appropriate.)

As I understand it (from Andrew), the tm.h files will eventually go
away.

For a some targets, there's a single tdep.c file, so constants like
the above can conveniently just be placed in the file itself.

For other targets, we have a family of tdep.c files.  The way I like
to think of it is as follows:

    <arch>-tdep.c	- main tdep.c file for a particular architecture
    <arch>-<os/abi>-tdep.c
    			- additional details for a particular OS or ABI
			  (i.e, signal handling, shared library support)

We *could* just concatenate all of these into one big <arch>-tdep.c
file, but I personally think it's cleaner to separate the details for
different ABIs into separate files.

Typically, you'll want to share a set of symbols between these files. 
The obvious way to handle this situation is a header file which is
included by the family of tdep.c files for a particular architecture.

Also,...  I've noticed that it is useful for the <arch>*-nat.c files
to sometimes know about these constants, so perhaps my choice of names
is not the best.

I would certainly appreciate advice on the best way to proceed.

Kevin