This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFC] Make GNU/Linux/PPC port work again
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.