Re: [PATCH/RFA] Generic OS ABI handling for PowerPC

[Kevin Buettner <kevinb@redhat.com>]

On May 28, 12:52pm, Jason R Thorpe wrote:

> On Tue, May 28, 2002 at 12:41:09PM -0700, Kevin Buettner wrote:
> 
>  > Why did you move the SVR4 ABI stuff out of ppc-linux-tdep.c?  I know
>  > there's a FIXME comment to that effect in this file, but I don't think
>  > that rs6000-tdep.c is really the right place for for the SVR4 ABI
>  > code.
> 
> Well, ppc-linux-tdep.c isn't exactly the right place for it, either.

Agreed, but I think it's a better place than rs6000-tdep.c.

> I could add another ppc-tdep.c file, but it seems to me that as long as
> rs6000-tdep.c makes references to sysv abi stuff, it should be actually in
> rs6000-tdep.c.

Umm... rs6000-tdep.c references ppc_linux_* functions too.  Are
you suggesting that they too should be moved to rs6000-tdep.c?

The way I view it is that (for historical reasons) rs6000-tdep.c
contains architecture specific code for the PowerPC and Power
architectures.  It also contains PowerOpen ABI specific code as well
as code specific to the AIX operating system.  BTW, the fact that it
contains PowerOpen ABI specific code is the reason that I object
to moving the SVR4 ABI specific code there.

IMO, ideally, the architecture specific code ought to go in it's own
file.  The ABI-specific code ought to go in separate files of their
own and inherit from the arch specific file.  The OS-dependent code
ought to go in still other files and ought to inherit from the ABI
specific code.  For the Power/PowerPC targets, I'd like to someday
break it down as follows:

    ppc-tdep.c		- generic Power / PowerPC architecture
    ppc-sysv-tdep.c	- PowerPC SysV ABI
    ppc-eabi-tdep.c	- PowerPC EABI
    ppc-poweropen-tdep.c - Power / PowerPC PowerOpen ABI (or whatever
			   it is that IBM's calling it these days.)
    ... (maybe more ABI specific files)
    ppc-linux-tdep.c	- Linux specific code for Power/PowerPC
    ppc-aix-tdep.c	- AIX specific code for Power/PowerPC
    ... (maybe more OS specific files)

The gdbarch machinery doesn't yet have an inheritance mechanism, so,
unfortunately, we're left with the situation whereby (e.g.) the
rs6000_gdbarch_init() function has to refer to a lot of code that it
really shouldn't be referring to.  It also makes arranging the code
as described above somewhat more difficult.

Kevin