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

[Michael Snyder <msnyder at cygnus dot com>]

Kevin Buettner wrote:
> 
> 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.

Do the values differ between various arch/mach combinations?
If so, you'll need to multi-arch them.
If not, I don't see why a single definition in the tm.h
file is not the way to go.