From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Stan Shebs , Kevin Buettner Cc: Michael Snyder , Nick Duffek , gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH RFC] Make GNU/Linux/PPC port work again Date: Wed, 19 Jul 2000 19:57:00 -0000 Message-id: <1000720025742.ZM16561@ocotillo.lan> 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/msg00192.html 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: > > > > -tdep.c - main tdep.c file for a particular architecture > > --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 -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 -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 _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 To: Michael Snyder Cc: Kevin Buettner , Nick Duffek , 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 To: Michael Snyder , Kevin Buettner Cc: Nick Duffek , 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 To: Stan Shebs Cc: Kevin Buettner , Michael Snyder , Nick Duffek , 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 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 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 for details on silicon.) brgds, H-P >From ezannoni@cygnus.com Thu Jul 20 18:02:00 2000 From: Elena Zannoni 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 * 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 To: Elena Zannoni 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 > > * 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 To: Michael Snyder Cc: Elena Zannoni , 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 > > > > * 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 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 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 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 * 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 - pointer to . */ 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 - pointer to . */ 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 To: Michael Snyder 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: 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.