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