From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: 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 16:13:00 -0000 Message-id: <39763610.9F8@cygnus.com> References: <1000719220642.ZM16166@ocotillo.lan> X-SW-Source: 2000-07/msg00185.html 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 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 16:29:00 -0000 Message-id: <1000719232847.ZM16284@ocotillo.lan> References: <1000719220642.ZM16166@ocotillo.lan> <39763610.9F8@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 To: GDB Patches 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 * 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 To: 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 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 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 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> 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: -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. 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 *-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 To: 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 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: > > -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". :-) Stan >From msnyder@cygnus.com Wed Jul 19 18:53:00 2000 From: Michael Snyder To: 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 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: > > -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. > > 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 *-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.