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

[Kevin Buettner <kevinb@cygnus.com>]

On Jul 19,  6:27pm, Stan Shebs wrote:

> > 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". :-)

I see your point - and am even aware of some places where this has
happened - but I believe your argument hinges on the premise that we
"can't/don't want to link in the inappropriate file just to get the
one function...".  However, once things are multi-arched, you *have*
to link in all of the ABI specific tdep.c files.  The reason for this
is that <arch>_gdbarch_init() is responsible for setting up the
various methods depending upon which ABI is getting used and it has to
know about all of them.  (Okay, you could avoid linking in these
various files if you're willing to introduce ifdefs into the code, but
I'm not willing to do this.)

E.g, in my (proposed) patches for rs6000-tdep.c, the following
bit of code was added to change the gdbarch initializations:

  if (osabi == ELFOSABI_LINUX)
    {
      set_gdbarch_frameless_function_invocation (gdbarch,
	ppc_linux_frameless_function_invocation);
      ...
    }
  else
    {
      set_gdbarch_frameless_function_invocation (gdbarch,
	rs6000_frameless_function_invocation);
      ...
    }

ppc_linux_frameless_function_invocation() is really linux specific
since the details concerning sigtramp frames are not spelled out in
the ABI.

But, in another part of the function, I have the following:

  if (sysv_abi)
    set_gdbarch_push_arguments (gdbarch, ppc_sysv_abi_push_arguments);
  else
    set_gdbarch_push_arguments (gdbarch, rs6000_push_arguments);

I've put ppc_sysv_abi_push_arguments() in ppc-linux-tdep.c, but
it will be used by non-linux targets as well.
From ac131313@cygnus.com Wed Jul 19 23:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: Kevin Buettner <kevinb@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 23:11:00 -0000
Message-id: <39769764.A1F49A05@cygnus.com>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com>
X-SW-Source: 2000-07/msg00193.html
Content-length: 1489

Michael Snyder wrote:
> 
> 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?

FYI,

Long term, I'd expect both config/*/tm-*.h and the tm.h link to go -
after all the'll only contain ``#define GDB_MULTI_ARCH NNN'' :-) 
Instead there'll be a new set of header files (ppc-tdep.h is as good a
guess as any) that the arch variants (rs6000-tdep.c, ppc-lnx-tdep.c)
would all include that target architecture specific header.

	Andrew
From ac131313@cygnus.com Wed Jul 19 23:24:00 2000
From: Andrew Cagney <ac131313@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 23:24:00 -0000
Message-id: <39769A98.9E16DC60@cygnus.com>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com> <1000719232847.ZM16284@ocotillo.lan> <397643BC.52B6@cygnus.com>
X-SW-Source: 2000-07/msg00194.html
Content-length: 1655

Michael Snyder wrote:

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

They don't belong in the multi-arch vector as they are architecture
specific.  As Kevin suggested, a ppc specific header file with PPC
specific prefixes.  When either a non PPC file includes that header or
when a non-ppc specific file tries to use that code directly alarm bells
should go off in peoples heads.

Within ppc-tdep.c, kevin might have:

	gdbarch_set_fp_regnum (...., PPC_FP_REGNUM)

enjoy,
	Andrew
From ac131313@cygnus.com Thu Jul 20 00:23:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@apple.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, 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: Thu, 20 Jul 2000 00:23:00 -0000
Message-id: <3976A83B.4BACE536@cygnus.com>
References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@cygnus.com> <1000719232847.ZM16284@ocotillo.lan> <397643BC.52B6@cygnus.com> <1000720005134.ZM16424@ocotillo.lan> <39765591.22FE213C@apple.com>
X-SW-Source: 2000-07/msg00195.html
Content-length: 2569

Stan Shebs wrote:

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

There are arguments for and against this.

One clear advantage of isolating OS specific code in OS specific files
is that the maintainer of that file/system can be given a greater level
of autonomy.  Provided they tow the party line and don't cross into
other areas (break tight clean interfaces) then a small amount of
duplication may help rather than hinder.

If a target function doesn't meet its contract then it can be fixed in
isolation by the maintainer without the risk of breaking anything else. 
If a target function tries to share functionality then the poor tester
is lost not knowing which of N different cases they might break. 
Eventually, the next generation of maintainers, get to remove the code
with a simple snip snip - no need to untangle it from anything else.

I suspect that the basic ISA and ABI are generic and can be shared (in
*-tdep.c).  A few more esoteric things - such as knowing that N
instructions after the _fork() entry point there is a trap intruction -
would be better separated out.  A chunck of code that includes
<minix/minix.h> and then starts grubing around in kernel structures
definitly deserves to be burried in its own little file.  Long term I
think there will be:

	o	create generic ISA/ABI

	o	refine ISA/ABI adding OS
		specific features

		I think OO people call this
		inheritance.

BTW, an example of how to not do things?  Look at
mips-tdep.c:mips_push-arguments().  It should have been separate
functions (in same or different files I don't care).  At present that
code can, in theory, handle 2^8 different cases - I test 32 of them.

	enjoy,
		Andrew

PS: With regard to re-aranging files and creating directories, I think
its time will come as soon as 5.1 goes out.  By then, a few more targets
will have been multi-arched so we will have a far better handle on the
issues.  In particular, the problems associated with trying to build a
GDB containing two orthogonal architectures will be clearer.
From hans-peter.nilsson@axis.com Thu Jul 20 11:13:00 2000
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: gdb-patches@sources.redhat.com
Cc: binutils@sources.redhat.com
Subject: config.sub updated (from subversions.gnu.org)
Date: Thu, 20 Jul 2000 11:13:00 -0000
Message-id: <200007201812.UAA06759@ignucius.axis.se>
X-SW-Source: 2000-07/msg00196.html
Content-length: 311

Just a heads-up for updated top-level files, as requested
some time ago.

As subject says, config.sub was updated from subversions.gnu.org
as of today, marked version='2000-07-06'.

Necessary for (not-so-)new target in binutils: CRIS.
(See <URL: http://developer.axis.com > for details on silicon.)

brgds, H-P
From ezannoni@cygnus.com Thu Jul 20 18:02:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Multiarch NUM_PSEUDO_REGS
Date: Thu, 20 Jul 2000 18:02:00 -0000
Message-id: <14711.41227.66134.188775@kwikemart.cygnus.com>
X-SW-Source: 2000-07/msg00197.html
Content-length: 3348

This is needed for some sh work I am doing....

Elena

2000-07-20  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

	* gdbarch.c (struct gdbarch): Add num_pseudo_regs field.
	(gdbarch_dump): Add NUM_PSEUDO_REGS to the dumped info.
	(gdbarch_num_pseudo_regs): New function.
	(set_gdbarch_num_pseudo_regs): New function.

	* gdbarch.h: Define NUM_PSEUDO_REGS as a gdbarch function.
	(gdbarch_num_pseudo_regs): Export.
	(set_gdbarch_num_pseudo_regs): Export.


Index: gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.23
diff -u -p -r1.23 gdbarch.h
cvs server: conflicting specifications of output style
--- gdbarch.h   2000/06/10 05:37:47     1.23
+++ gdbarch.h   2000/07/21 00:56:12
@@ -239,6 +239,14 @@ extern void set_gdbarch_num_regs (struct
 #endif
 #endif
 
+extern int gdbarch_num_pseudo_regs (struct gdbarch *gdbarch);
+extern void set_gdbarch_num_pseudo_regs (struct gdbarch *gdbarch, int num_pseudo_regs);
+#if GDB_MULTI_ARCH
+#if (GDB_MULTI_ARCH > 1) || !defined (NUM_PSEUDO_REGS)
+#define NUM_PSEUDO_REGS (gdbarch_num_pseudo_regs (current_gdbarch))
+#endif
+#endif
+
 extern int gdbarch_sp_regnum (struct gdbarch *gdbarch);
 extern void set_gdbarch_sp_regnum (struct gdbarch *gdbarch, int sp_regnum);
 #if GDB_MULTI_ARCH

Index: gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.29
diff -c -p -u -r1.29 gdbarch.c
cvs server: conflicting specifications of output style
--- gdbarch.c   2000/06/12 00:35:33     1.29
+++ gdbarch.c   2000/07/21 01:01:03
@@ -145,6 +145,7 @@ struct gdbarch
   gdbarch_read_sp_ftype *read_sp;
   gdbarch_write_sp_ftype *write_sp;
   int num_regs;
+  int num_pseudo_regs;
   int sp_regnum;
   int fp_regnum;
   int pc_regnum;
@@ -775,6 +776,11 @@ gdbarch_dump (struct gdbarch *gdbarch, s
                       "gdbarch_dump: NUM_REGS # %s\n",
                       XSTRING (NUM_REGS));
 #endif
+#ifdef NUM_PSEUDO_REGS
+  fprintf_unfiltered (file,
+                      "gdbarch_dump: NUM_PSEUDO_REGS # %s\n",
+                      XSTRING (NUM_PSEUDO_REGS));
+#endif
 #ifdef SP_REGNUM
   fprintf_unfiltered (file,
                       "gdbarch_dump: SP_REGNUM # %s\n",
@@ -1348,6 +1354,11 @@ gdbarch_dump (struct gdbarch *gdbarch, s
                       "gdbarch_dump: NUM_REGS = %ld\n",
                       (long) NUM_REGS);
 #endif
+#ifdef NUM_PSEUDO_REGS
+  fprintf_unfiltered (file,
+                      "gdbarch_dump: NUM_PSEUDO_REGS = %ld\n",
+                      (long) NUM_PSEUDO_REGS);
+#endif
 #ifdef SP_REGNUM
   fprintf_unfiltered (file,
                       "gdbarch_dump: SP_REGNUM = %ld\n",
@@ -2166,6 +2177,23 @@ set_gdbarch_num_regs (struct gdbarch *gd
                       int num_regs)
 {
   gdbarch->num_regs = num_regs;
+}
+
+int
+gdbarch_num_pseudo_regs (struct gdbarch *gdbarch)
+{
+  if (gdbarch->num_pseudo_regs == -1)
+    internal_error ("gdbarch: gdbarch_num_pseudo_regs invalid");
+  if (gdbarch_debug >= 2)
+    fprintf_unfiltered (gdb_stdlog, "gdbarch_num_pseudo_regs called\n");
+  return gdbarch->num_pseudo_regs;
+}
+
+void
+set_gdbarch_num_pseudo_regs (struct gdbarch *gdbarch,
+                      int num_pseudo_regs)
+{
+  gdbarch->num_pseudo_regs = num_pseudo_regs;
 }
 
 int
From msnyder@cygnus.com Thu Jul 20 18:23:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Multiarch NUM_PSEUDO_REGS
Date: Thu, 20 Jul 2000 18:23:00 -0000
Message-id: <3977A5F3.2B9D@cygnus.com>
References: <14711.41227.66134.188775@kwikemart.cygnus.com>
X-SW-Source: 2000-07/msg00198.html
Content-length: 3673

Elena Zannoni wrote:
> 
> This is needed for some sh work I am doing....

Thanks, I'm off the hook for THAT one...   ;-)

> 
> Elena
> 
> 2000-07-20  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
> 
>         * gdbarch.c (struct gdbarch): Add num_pseudo_regs field.
>         (gdbarch_dump): Add NUM_PSEUDO_REGS to the dumped info.
>         (gdbarch_num_pseudo_regs): New function.
>         (set_gdbarch_num_pseudo_regs): New function.
> 
>         * gdbarch.h: Define NUM_PSEUDO_REGS as a gdbarch function.
>         (gdbarch_num_pseudo_regs): Export.
>         (set_gdbarch_num_pseudo_regs): Export.
> 
> Index: gdbarch.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbarch.h,v
> retrieving revision 1.23
> diff -u -p -r1.23 gdbarch.h
> cvs server: conflicting specifications of output style
> --- gdbarch.h   2000/06/10 05:37:47     1.23
> +++ gdbarch.h   2000/07/21 00:56:12
> @@ -239,6 +239,14 @@ extern void set_gdbarch_num_regs (struct
>  #endif
>  #endif
> 
> +extern int gdbarch_num_pseudo_regs (struct gdbarch *gdbarch);
> +extern void set_gdbarch_num_pseudo_regs (struct gdbarch *gdbarch, int num_pseudo_regs);
> +#if GDB_MULTI_ARCH
> +#if (GDB_MULTI_ARCH > 1) || !defined (NUM_PSEUDO_REGS)
> +#define NUM_PSEUDO_REGS (gdbarch_num_pseudo_regs (current_gdbarch))
> +#endif
> +#endif
> +
>  extern int gdbarch_sp_regnum (struct gdbarch *gdbarch);
>  extern void set_gdbarch_sp_regnum (struct gdbarch *gdbarch, int sp_regnum);
>  #if GDB_MULTI_ARCH
> 
> Index: gdbarch.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbarch.c,v
> retrieving revision 1.29
> diff -c -p -u -r1.29 gdbarch.c
> cvs server: conflicting specifications of output style
> --- gdbarch.c   2000/06/12 00:35:33     1.29
> +++ gdbarch.c   2000/07/21 01:01:03
> @@ -145,6 +145,7 @@ struct gdbarch
>    gdbarch_read_sp_ftype *read_sp;
>    gdbarch_write_sp_ftype *write_sp;
>    int num_regs;
> +  int num_pseudo_regs;
>    int sp_regnum;
>    int fp_regnum;
>    int pc_regnum;
> @@ -775,6 +776,11 @@ gdbarch_dump (struct gdbarch *gdbarch, s
>                        "gdbarch_dump: NUM_REGS # %s\n",
>                        XSTRING (NUM_REGS));
>  #endif
> +#ifdef NUM_PSEUDO_REGS
> +  fprintf_unfiltered (file,
> +                      "gdbarch_dump: NUM_PSEUDO_REGS # %s\n",
> +                      XSTRING (NUM_PSEUDO_REGS));
> +#endif
>  #ifdef SP_REGNUM
>    fprintf_unfiltered (file,
>                        "gdbarch_dump: SP_REGNUM # %s\n",
> @@ -1348,6 +1354,11 @@ gdbarch_dump (struct gdbarch *gdbarch, s
>                        "gdbarch_dump: NUM_REGS = %ld\n",
>                        (long) NUM_REGS);
>  #endif
> +#ifdef NUM_PSEUDO_REGS
> +  fprintf_unfiltered (file,
> +                      "gdbarch_dump: NUM_PSEUDO_REGS = %ld\n",
> +                      (long) NUM_PSEUDO_REGS);
> +#endif
>  #ifdef SP_REGNUM
>    fprintf_unfiltered (file,
>                        "gdbarch_dump: SP_REGNUM = %ld\n",
> @@ -2166,6 +2177,23 @@ set_gdbarch_num_regs (struct gdbarch *gd
>                        int num_regs)
>  {
>    gdbarch->num_regs = num_regs;
> +}
> +
> +int
> +gdbarch_num_pseudo_regs (struct gdbarch *gdbarch)
> +{
> +  if (gdbarch->num_pseudo_regs == -1)
> +    internal_error ("gdbarch: gdbarch_num_pseudo_regs invalid");
> +  if (gdbarch_debug >= 2)
> +    fprintf_unfiltered (gdb_stdlog, "gdbarch_num_pseudo_regs called\n");
> +  return gdbarch->num_pseudo_regs;
> +}
> +
> +void
> +set_gdbarch_num_pseudo_regs (struct gdbarch *gdbarch,
> +                      int num_pseudo_regs)
> +{
> +  gdbarch->num_pseudo_regs = num_pseudo_regs;
>  }
> 
>  int
From ezannoni@cygnus.com Thu Jul 20 18:25:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Multiarch NUM_PSEUDO_REGS
Date: Thu, 20 Jul 2000 18:25:00 -0000
Message-id: <14711.42626.347443.785983@kwikemart.cygnus.com>
References: <14711.41227.66134.188775@kwikemart.cygnus.com> <3977A5F3.2B9D@cygnus.com>
X-SW-Source: 2000-07/msg00199.html
Content-length: 4093

Michael Snyder writes:
 > Elena Zannoni wrote:
 > > 
 > > This is needed for some sh work I am doing....
 > 
 > Thanks, I'm off the hook for THAT one...   ;-)

If the patch is correct, that is. I am having second thoughts. 

Elena

 > 
 > > 
 > > Elena
 > > 
 > > 2000-07-20  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
 > > 
 > >         * gdbarch.c (struct gdbarch): Add num_pseudo_regs field.
 > >         (gdbarch_dump): Add NUM_PSEUDO_REGS to the dumped info.
 > >         (gdbarch_num_pseudo_regs): New function.
 > >         (set_gdbarch_num_pseudo_regs): New function.
 > > 
 > >         * gdbarch.h: Define NUM_PSEUDO_REGS as a gdbarch function.
 > >         (gdbarch_num_pseudo_regs): Export.
 > >         (set_gdbarch_num_pseudo_regs): Export.
 > > 
 > > Index: gdbarch.h
 > > ===================================================================
 > > RCS file: /cvs/src/src/gdb/gdbarch.h,v
 > > retrieving revision 1.23
 > > diff -u -p -r1.23 gdbarch.h
 > > cvs server: conflicting specifications of output style
 > > --- gdbarch.h   2000/06/10 05:37:47     1.23
 > > +++ gdbarch.h   2000/07/21 00:56:12
 > > @@ -239,6 +239,14 @@ extern void set_gdbarch_num_regs (struct
 > >  #endif
 > >  #endif
 > > 
 > > +extern int gdbarch_num_pseudo_regs (struct gdbarch *gdbarch);
 > > +extern void set_gdbarch_num_pseudo_regs (struct gdbarch *gdbarch, int num_pseudo_regs);
 > > +#if GDB_MULTI_ARCH
 > > +#if (GDB_MULTI_ARCH > 1) || !defined (NUM_PSEUDO_REGS)
 > > +#define NUM_PSEUDO_REGS (gdbarch_num_pseudo_regs (current_gdbarch))
 > > +#endif
 > > +#endif
 > > +
 > >  extern int gdbarch_sp_regnum (struct gdbarch *gdbarch);
 > >  extern void set_gdbarch_sp_regnum (struct gdbarch *gdbarch, int sp_regnum);
 > >  #if GDB_MULTI_ARCH
 > > 
 > > Index: gdbarch.c
 > > ===================================================================
 > > RCS file: /cvs/src/src/gdb/gdbarch.c,v
 > > retrieving revision 1.29
 > > diff -c -p -u -r1.29 gdbarch.c
 > > cvs server: conflicting specifications of output style
 > > --- gdbarch.c   2000/06/12 00:35:33     1.29
 > > +++ gdbarch.c   2000/07/21 01:01:03
 > > @@ -145,6 +145,7 @@ struct gdbarch
 > >    gdbarch_read_sp_ftype *read_sp;
 > >    gdbarch_write_sp_ftype *write_sp;
 > >    int num_regs;
 > > +  int num_pseudo_regs;
 > >    int sp_regnum;
 > >    int fp_regnum;
 > >    int pc_regnum;
 > > @@ -775,6 +776,11 @@ gdbarch_dump (struct gdbarch *gdbarch, s
 > >                        "gdbarch_dump: NUM_REGS # %s\n",
 > >                        XSTRING (NUM_REGS));
 > >  #endif
 > > +#ifdef NUM_PSEUDO_REGS
 > > +  fprintf_unfiltered (file,
 > > +                      "gdbarch_dump: NUM_PSEUDO_REGS # %s\n",
 > > +                      XSTRING (NUM_PSEUDO_REGS));
 > > +#endif
 > >  #ifdef SP_REGNUM
 > >    fprintf_unfiltered (file,
 > >                        "gdbarch_dump: SP_REGNUM # %s\n",
 > > @@ -1348,6 +1354,11 @@ gdbarch_dump (struct gdbarch *gdbarch, s
 > >                        "gdbarch_dump: NUM_REGS = %ld\n",
 > >                        (long) NUM_REGS);
 > >  #endif
 > > +#ifdef NUM_PSEUDO_REGS
 > > +  fprintf_unfiltered (file,
 > > +                      "gdbarch_dump: NUM_PSEUDO_REGS = %ld\n",
 > > +                      (long) NUM_PSEUDO_REGS);
 > > +#endif
 > >  #ifdef SP_REGNUM
 > >    fprintf_unfiltered (file,
 > >                        "gdbarch_dump: SP_REGNUM = %ld\n",
 > > @@ -2166,6 +2177,23 @@ set_gdbarch_num_regs (struct gdbarch *gd
 > >                        int num_regs)
 > >  {
 > >    gdbarch->num_regs = num_regs;
 > > +}
 > > +
 > > +int
 > > +gdbarch_num_pseudo_regs (struct gdbarch *gdbarch)
 > > +{
 > > +  if (gdbarch->num_pseudo_regs == -1)
 > > +    internal_error ("gdbarch: gdbarch_num_pseudo_regs invalid");
 > > +  if (gdbarch_debug >= 2)
 > > +    fprintf_unfiltered (gdb_stdlog, "gdbarch_num_pseudo_regs called\n");
 > > +  return gdbarch->num_pseudo_regs;
 > > +}
 > > +
 > > +void
 > > +set_gdbarch_num_pseudo_regs (struct gdbarch *gdbarch,
 > > +                      int num_pseudo_regs)
 > > +{
 > > +  gdbarch->num_pseudo_regs = num_pseudo_regs;
 > >  }
 > > 
 > >  int
From msnyder@cygnus.com Thu Jul 20 18:41:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: [RFA]: opcodes / i386 disassembler
Date: Thu, 20 Jul 2000 18:41:00 -0000
Message-id: <200007210141.SAA21236@cleaver.cygnus.com>
X-SW-Source: 2000-07/msg00200.html
Content-length: 3561

Would the following be acceptable?  Assuming I provided an
suitable ChangeLog entry?

Index: i386-dis.c
===================================================================
RCS file: /cvs/cvsfiles/devo/opcodes/i386-dis.c,v
retrieving revision 1.51
diff -p -r1.51 i386-dis.c
*** i386-dis.c	2000/04/05 20:16:40	1.51
--- i386-dis.c	2000/07/21 01:40:08
*************** You should have received a copy of the G
*** 18,38 ****
  along with this program; if not, write to the Free Software
  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
  
! /*
!  * 80386 instruction printer by Pace Willisson (pace@prep.ai.mit.edu)
!  * July 1988
!  *  modified by John Hassey (hassey@dg-rtp.dg.com)
!  */
! 
! /*
!  * The main tables describing the instructions is essentially a copy
!  * of the "Opcode Map" chapter (Appendix A) of the Intel 80386
!  * Programmers Manual.  Usually, there is a capital letter, followed
!  * by a small letter.  The capital letter tell the addressing mode,
!  * and the small letter tells about the operand size.  Refer to
!  * the Intel manual for details.
!  */
  
  #include "dis-asm.h"
  #include "sysdep.h"
  #include "opintl.h"
--- 18,34 ----
  along with this program; if not, write to the Free Software
  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
  
! /* 80386 instruction printer by Pace Willisson (pace@prep.ai.mit.edu)
!    July 1988, modified by John Hassey (hassey@dg-rtp.dg.com).  */
  
+ /* The main tables describing the instructions is essentially a copy
+    of the "Opcode Map" chapter (Appendix A) of the Intel 80386
+    Programmers Manual and the Pentium(TM) Family User's Manual.
+    Usually, there is a capital letter, followed by a small letter.
+    The capital letter tell the addressing mode, and the small letter
+    tells about the operand size.  Refer to the Intel manual for
+    details.  */
+ 
  #include "dis-asm.h"
  #include "sysdep.h"
  #include "opintl.h"
*************** static const struct dis386 dis386_att[] 
*** 496,502 ****
    /* 80 */
    { GRP1b },
    { GRP1S },
!   { "(bad)",	XX, XX, XX },
    { GRP1Ss },
    { "testB",	Eb, Gb, XX },
    { "testS",	Ev, Gv, XX },
--- 492,509 ----
    /* 80 */
    { GRP1b },
    { GRP1S },
!   /* this one is blank in appendix A of the 386 book, and given as
!      "MOVB AL, imm8 in appendix A of the Pentium book with a footnote
!      saying "Reserved"; it *should* be "Immediate Grp1, Ev, Ib"
!      according to an Intel person who says it'll be fixed in the -004
!      version of the Pentium book.
! 
!      The trick here is that 0x80 sets neither the "s" nor the "w" bit,
!      while 0x82 sets the "s" bit but not the "w" bit.  However, if the
!      "w" bit isn't set, the setting of the "s" bit is irrelevant, as
!      the operands are one byte long, so there's no sign-extension to be
!      done. */
!   { GRP1b  },
    { GRP1Ss },
    { "testB",	Eb, Gb, XX },
    { "testS",	Ev, Gv, XX },
*************** static const struct dis386 dis386_twobyt
*** 968,974 ****
    { "(bad)", XX, XX, XX },
    { "(bad)", XX, XX, XX },
    /* 20 */
!   /* these are all backward in appendix A of the intel book */
    { "movL", Rd, Cd, XX },
    { "movL", Rd, Dd, XX },
    { "movL", Cd, Rd, XX },
--- 975,982 ----
    { "(bad)", XX, XX, XX },
    { "(bad)", XX, XX, XX },
    /* 20 */
!   /* these are all backward in appendix A of the intel book,
!      but correct in appendix A of the Pentium book.  */
    { "movL", Rd, Cd, XX },
    { "movL", Rd, Dd, XX },
    { "movL", Cd, Rd, XX },
From msnyder@cygnus.com Thu Jul 20 18:43:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: [RFA]: opcodes alpha disassembler
Date: Thu, 20 Jul 2000 18:43:00 -0000
Message-id: <200007210143.SAA21952@cleaver.cygnus.com>
X-SW-Source: 2000-07/msg00201.html
Content-length: 5284

Would the following be acceptable, with a suitable ChangeLog?

Index: alpha-opc.c
===================================================================
RCS file: /cvs/cvsfiles/devo/opcodes/alpha-opc.c,v
retrieving revision 1.13
diff -p -r1.13 alpha-opc.c
*** alpha-opc.c	2000/04/28 13:38:26	1.13
--- alpha-opc.c	2000/07/21 01:42:46
***************
*** 26,53 ****
  #include "bfd.h"
  #include "opintl.h"
  
! /* This file holds the Alpha AXP opcode table.  The opcode table includes
!    almost all of the extended instruction mnemonics.  This permits the
!    disassembler to use them, and simplifies the assembler logic, at the
!    cost of increasing the table size.  The table is strictly constant
!    data, so the compiler should be able to put it in the .text section.
  
-    This file also holds the operand table.  All knowledge about inserting
-    operands into instructions and vice-versa is kept in this file.
- 
     The information for the base instruction set was compiled from the
     _Alpha Architecture Handbook_, Digital Order Number EC-QD2KB-TE,
     version 2.
  
!    The information for the post-ev5 architecture extensions BWX, CIX and
!    MAX came from version 3 of this same document, which is also available
!    on-line at http://ftp.digital.com/pub/Digital/info/semiconductor
!    /literature/alphahb2.pdf
  
     The information for the EV4 PALcode instructions was compiled from
!    _DECchip 21064 and DECchip 21064A Alpha AXP Microprocessors Hardware
!    Reference Manual_, Digital Order Number EC-Q9ZUA-TE, preliminary
!    revision dated June 1994.
  
     The information for the EV5 PALcode instructions was compiled from
     _Alpha 21164 Microprocessor Hardware Reference Manual_, Digital
--- 26,56 ----
  #include "bfd.h"
  #include "opintl.h"
  
! /* This file holds the Alpha AXP opcode table.  The opcode table
!    includes almost all of the extended instruction mnemonics.  This
!    permits the disassembler to use them, and simplifies the assembler
!    logic, at the cost of increasing the table size.  The table is
!    strictly constant data, so the compiler should be able to put it in
!    the .text section.
! 
!    This file also holds the operand table.  All knowledge about
!    inserting operands into instructions and vice-versa is kept in this
!    file.
  
     The information for the base instruction set was compiled from the
     _Alpha Architecture Handbook_, Digital Order Number EC-QD2KB-TE,
     version 2.
  
!    The information for the post-ev5 architecture extensions BWX, CIX
!    and MAX, and for the Digital UNIX PALcode calls, came from version
!    4 of this same document, which is also available on-line at
!    http://ftp.digital.com/pub/Digital/info/semiconductor/literature/
!    alphaahb.pdf
  
     The information for the EV4 PALcode instructions was compiled from
!    _DECchip 21064 and DECchip 21064A Alpha AXP Microprocessors
!    Hardware Reference Manual_, Digital Order Number EC-Q9ZUA-TE,
!    preliminary revision dated June 1994.
  
     The information for the EV5 PALcode instructions was compiled from
     _Alpha 21164 Microprocessor Hardware Reference Manual_, Digital
*************** extract_ev6hwjhint(insn, invalid)
*** 531,541 ****
--- 534,573 ----
  
  const struct alpha_opcode alpha_opcodes[] = {
    { "halt",		SPCD(0x00,0x0000), BASE, ARG_NONE },
+   { "cflush",		SPCD(0x00,0x0001), BASE, ARG_NONE },
    { "draina",		SPCD(0x00,0x0002), BASE, ARG_NONE },
+   { "cserve",		SPCD(0x00,0x0009), BASE, ARG_NONE },
+   { "swppal",		SPCD(0x00,0x000A), BASE, ARG_NONE },
+   { "wripir",		SPCD(0x00,0x000D), BASE, ARG_NONE },
+   { "rdmces",		SPCD(0x00,0x0010), BASE, ARG_NONE },
+   { "wrmces",		SPCD(0x00,0x0011), BASE, ARG_NONE },
+   { "wrfen",		SPCD(0x00,0x002B), BASE, ARG_NONE },
+   { "wrvptptr",		SPCD(0x00,0x002D), BASE, ARG_NONE },
+   { "swpctx",		SPCD(0x00,0x0030), BASE, ARG_NONE },
+   { "wrval",		SPCD(0x00,0x0031), BASE, ARG_NONE },
+   { "rdval",		SPCD(0x00,0x0032), BASE, ARG_NONE },
+   { "tbi",		SPCD(0x00,0x0033), BASE, ARG_NONE },
+   { "wrent",		SPCD(0x00,0x0034), BASE, ARG_NONE },
+   { "swpipl",		SPCD(0x00,0x0035), BASE, ARG_NONE },
+   { "rdps",		SPCD(0x00,0x0036), BASE, ARG_NONE },
+   { "wrkgp",		SPCD(0x00,0x0037), BASE, ARG_NONE },
+   { "wrusp",		SPCD(0x00,0x0038), BASE, ARG_NONE },
+   { "wrperfmon",	SPCD(0x00,0x0039), BASE, ARG_NONE },
+   { "rdusp",		SPCD(0x00,0x003A), BASE, ARG_NONE },
+   { "whami",		SPCD(0x00,0x003C), BASE, ARG_NONE },
+   { "retsys",		SPCD(0x00,0x003D), BASE, ARG_NONE },
+   { "wtint",		SPCD(0x00,0x003E), BASE, ARG_NONE },
+   { "rti",		SPCD(0x00,0x003F), BASE, ARG_NONE },
    { "bpt",		SPCD(0x00,0x0080), BASE, ARG_NONE },
+   { "bugchk",		SPCD(0x00,0x0081), BASE, ARG_NONE },
    { "callsys",		SPCD(0x00,0x0083), BASE, ARG_NONE },
    { "chmk", 		SPCD(0x00,0x0083), BASE, ARG_NONE },
    { "imb",		SPCD(0x00,0x0086), BASE, ARG_NONE },
+   { "urti",		SPCD(0x00,0x0092), BASE, ARG_NONE },
+   { "rdunique",		SPCD(0x00,0x009E), BASE, ARG_NONE },
+   { "wrunique",		SPCD(0x00,0x009F), BASE, ARG_NONE },
+   { "gentrap",		SPCD(0x00,0x00AA), BASE, ARG_NONE },
+   { "clrfen",		SPCD(0x00,0x00AE), BASE, ARG_NONE },
    { "call_pal",		PCD(0x00), BASE, ARG_PCD },
    { "pal",		PCD(0x00), BASE, ARG_PCD },		/* alias */
  
From msnyder@cygnus.com Thu Jul 20 18:52:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: valarith fixup
Date: Thu, 20 Jul 2000 18:52:00 -0000
Message-id: <200007210152.SAA24963@cleaver.cygnus.com>
X-SW-Source: 2000-07/msg00202.html
Content-length: 1149

2000-07-20  Michael Snyder  <msnyder@cleaver.cygnus.com>

        * valarith.c (value_sub): Call check_typedef.

Index: valarith.c
===================================================================
RCS file: /cvs/src/src/gdb/valarith.c,v
retrieving revision 1.3
diff -p -r1.3 valarith.c
*** valarith.c	2000/05/28 01:12:33	1.3
--- valarith.c	2000/07/21 01:51:37
*************** value_sub (arg1, arg2)
*** 110,117 ****
  				      - (sz * value_as_long (arg2))));
  	}
        else if (TYPE_CODE (type2) == TYPE_CODE_PTR
! 	       && TYPE_LENGTH (TYPE_TARGET_TYPE (type1))
! 	       == TYPE_LENGTH (TYPE_TARGET_TYPE (type2)))
  	{
  	  /* pointer to <type x> - pointer to <type x>.  */
  	  LONGEST sz = TYPE_LENGTH (check_typedef (TYPE_TARGET_TYPE (type1)));
--- 110,117 ----
  				      - (sz * value_as_long (arg2))));
  	}
        else if (TYPE_CODE (type2) == TYPE_CODE_PTR
! 	       && TYPE_LENGTH (check_typedef (TYPE_TARGET_TYPE (type1)))
! 	       == TYPE_LENGTH (check_typedef (TYPE_TARGET_TYPE (type2))))
  	{
  	  /* pointer to <type x> - pointer to <type x>.  */
  	  LONGEST sz = TYPE_LENGTH (check_typedef (TYPE_TARGET_TYPE (type1)));
From alan@linuxcare.com.au Thu Jul 20 18:59:00 2000
From: Alan Modra <alan@linuxcare.com.au>
To: Michael Snyder <msnyder@cygnus.com>
Cc: binutils@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA]: opcodes / i386 disassembler
Date: Thu, 20 Jul 2000 18:59:00 -0000
Message-id: <Pine.LNX.4.21.0007211152270.18897-100000@front.linuxcare.com.au>
References: <200007210141.SAA21236@cleaver.cygnus.com>
X-SW-Source: 2000-07/msg00203.html
Content-length: 453

On Thu, 20 Jul 2000, Michael Snyder wrote:

> Would the following be acceptable?  Assuming I provided an
> suitable ChangeLog entry?

Yes.  Please check it in.  The x86 instruction set has many of these cases
where there's more than one encoding of an instruction.  Some people even
used this feature to store covert messages in code - eg. to brand code as
being produced by a certain assembler.

Alan Modra
-- 
Linuxcare.  Support for the Revolution.