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

[Michael Snyder <msnyder@cygnus.com>]

Kevin Buettner wrote:
> 
> The patch below makes the GNU/Linux/PPC port work again.
> 
> I haven't tested it with other Power or PowerPC targets or native
> configurations; it is possible that I inadvertently broke something...
> I'd appreciate it if those of you (hi Nick!) affected by this code
> would test it before I commit this patch.
> 
> Long term, I'd like to introduce a new file called ppc-tdep.c which
> contains the generic target methods for the Power and PowerPC
> architectures.  (Much of the code in rs6000-tdep.c would be moved to
> this file.) rs6000-tdep.c would become an AIX specific file that knows
> about shared libraries, signal handlers, and anything else specific to
> AIX.  It would play the same role for AIX that ppc-linux-tdep.c plays
> for Linux.  (The other way to do it would be to remove the AIXisms
> from rs6000-tdep.c and create a new file named ppc-aix-tdep.c which
> knows about the AIXisms.)
> 
>         * 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?
From kevinb@cygnus.com Wed Jul 19 16:29:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>
Cc: Nick Duffek <nsd@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Make GNU/Linux/PPC port work again
Date: Wed, 19 Jul 2000 16:29:00 -0000
Message-id: <1000719232847.ZM16284@ocotillo.lan>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com> <msnyder@cygnus.com>
X-SW-Source: 2000-07/msg00186.html
Content-length: 1668

On Jul 19,  4:13pm, Michael Snyder wrote:

> Kevin Buettner wrote:

> > Long term, I'd like to introduce a new file called ppc-tdep.c which
> > contains the generic target methods for the Power and PowerPC
> > architectures.  (Much of the code in rs6000-tdep.c would be moved to
> > this file.) rs6000-tdep.c would become an AIX specific file that knows
> > about shared libraries, signal handlers, and anything else specific to
> > AIX.  It would play the same role for AIX that ppc-linux-tdep.c plays
> > for Linux.  (The other way to do it would be to remove the AIXisms
> > from rs6000-tdep.c and create a new file named ppc-aix-tdep.c which
> > knows about the AIXisms.)
> > 
> >         * 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.
From ac131313@cygnus.com Wed Jul 19 17:01:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [patch/sim/mips] Update mips16 breakpoint
Date: Wed, 19 Jul 2000 17:01:00 -0000
Message-id: <39764125.6162A3CF@cygnus.com>
X-SW-Source: 2000-07/msg00187.html
Content-length: 903

FYI,

The attatched updates the MIPS16 breakpoint so that it works with a few
other more recent changes (to do with being able to halt and then step
into a signal).

	Andrew
Wed Jul 19 18:50:51 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* m16.igen (break): Call SignalException not sim_engine_halt.

Index: m16.igen
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/mips/m16.igen,v
retrieving revision 1.11
diff -p -r1.11 m16.igen
*** m16.igen	2000/03/02 09:19:19	1.11
--- m16.igen	2000/07/19 23:58:49
***************
*** 1616,1620 ****
      PC = cia - 2; /* reference the branch instruction */
    else
      PC = cia;
!   sim_engine_halt (SD, CPU, NULL, cia, sim_stopped, SIM_SIGTRAP);
  }
--- 1616,1620 ----
      PC = cia - 2; /* reference the branch instruction */
    else
      PC = cia;
!   SignalException (BreakPoint, instruction_0);
  }
From msnyder@cygnus.com Wed Jul 19 17:11:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Nick Duffek <nsd@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Make GNU/Linux/PPC port work again
Date: Wed, 19 Jul 2000 17:11:00 -0000
Message-id: <397643BC.52B6@cygnus.com>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com> <1000719232847.ZM16284@ocotillo.lan>
X-SW-Source: 2000-07/msg00188.html
Content-length: 2289

Kevin Buettner wrote:
> 
> On Jul 19,  4:13pm, Michael Snyder wrote:
> 
> > Kevin Buettner wrote:
> 
> > > Long term, I'd like to introduce a new file called ppc-tdep.c which
> > > contains the generic target methods for the Power and PowerPC
> > > architectures.  (Much of the code in rs6000-tdep.c would be moved to
> > > this file.) rs6000-tdep.c would become an AIX specific file that knows
> > > about shared libraries, signal handlers, and anything else specific to
> > > AIX.  It would play the same role for AIX that ppc-linux-tdep.c plays
> > > for Linux.  (The other way to do it would be to remove the AIXisms
> > > from rs6000-tdep.c and create a new file named ppc-aix-tdep.c which
> > > knows about the AIXisms.)
> > >
> > >         * 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, I know it is a pain that whenever you touch that file
your entire build directory recompiles, but it's a fact of
life in gdb-land.

Mcihael
From kevinb@cygnus.com Wed Jul 19 17:51:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>, Kevin Buettner <kevinb@cygnus.com>
Cc: Nick Duffek <nsd@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Make GNU/Linux/PPC port work again
Date: Wed, 19 Jul 2000 17:51:00 -0000
Message-id: <1000720005134.ZM16424@ocotillo.lan>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com> <1000719232847.ZM16284@ocotillo.lan> <397643BC.52B6@cygnus.com> <msnyder@cygnus.com>
X-SW-Source: 2000-07/msg00189.html
Content-length: 2894

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
From shebs@apple.com Wed Jul 19 18:27:00 2000
From: Stan Shebs <shebs@apple.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Michael Snyder <msnyder@cygnus.com>, Nick Duffek <nsd@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Make GNU/Linux/PPC port work again
Date: Wed, 19 Jul 2000 18:27:00 -0000
Message-id: <39765591.22FE213C@apple.com>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com> <1000719232847.ZM16284@ocotillo.lan> <397643BC.52B6@cygnus.com> <1000720005134.ZM16424@ocotillo.lan>
X-SW-Source: 2000-07/msg00190.html
Content-length: 2136

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

I suspect that in the long run your approach will probably be what
ends up getting used, but we ought to plan it a little more before
acting.  For instance, the suggestion of moving platform-specific
sources into subdirs has been raised by several folks recently, and
I think it's worth reconsidering.  For now I'd vote to leave things
in tm.h so that when the time comes, there won't be "Kevin's weird
header files" :-) to figure out how to deal with.

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

Let me take this opportunity to warn people of what usually happens
when we do this.  You need a piece of functionality in an OS/ABI
file, because contrary to what the original author thought, it's useful
for more than one OS or ABI.  Since you can't/don't want to link in the
inappropriate file just to get the one function, cut-n-paste rides into
town to, ahem, save the day, and voila, two copies of the same function
to maintain.  The next generation of maintainers hack one and not the
other, and we end up with two functions that are different, but it's
not clear why.

So one of the advantages of having a common <arch>-tdep.c is that it
strongly encourages people to share code that is common among systems
using the same type of CPU.  We can get the same effect by being
vigilant, but, as the DOJ said to Microsoft, "we prefer structural
remedies because it's less work for us". :-)

Stan
From msnyder@cygnus.com Wed Jul 19 18:53:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Nick Duffek <nsd@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Make GNU/Linux/PPC port work again
Date: Wed, 19 Jul 2000 18:53:00 -0000
Message-id: <39764E34.3B54@cygnus.com>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com> <1000719232847.ZM16284@ocotillo.lan> <397643BC.52B6@cygnus.com> <1000720005134.ZM16424@ocotillo.lan>
X-SW-Source: 2000-07/msg00191.html
Content-length: 3272

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.