GCC policy question

GCC policy question

[Stan Shebs]

One of the big required chunks that will be in Apple's patches
for GCC is support for "Mach-O PIC" code generation.  I'm
still working on grokking it, but one of its properties is that
it's mostly machine-independent, and the same code is used for
both PowerPC and x86 (and other processors that NeXT used to
support).  So there's a moderately hefty file machopic.c that
implements all the functions, which are connected to various
macros in tm.h.

Right now this file and others live in a subdirectory config/apple.
My question is: should it?  At the moment, the only OS-dedicated
subdirs are config/msdos and config/winnt.  config/ itself is a
possibility; there is a very old nextstep.c already there.  I also
note a halfpic.c in the main dir for OSF's version, presumably
machopic could live there.  Finally, if necessary to conform to
policy, I could clone the code, one for each target; but that
seems undesirable.

Which way should I go?

Stan

Re: GCC policy question

[Jeffrey A Law]

 In message <38F7AA46.3646F7D6@apple.com>you write:
  > One of the big required chunks that will be in Apple's patches
  > for GCC is support for "Mach-O PIC" code generation.  I'm
  > still working on grokking it, but one of its properties is that
  > it's mostly machine-independent, and the same code is used for
  > both PowerPC and x86 (and other processors that NeXT used to
  > support).  So there's a moderately hefty file machopic.c that
  > implements all the functions, which are connected to various
  > macros in tm.h.
  > 
  > Right now this file and others live in a subdirectory config/apple.
  > My question is: should it?  At the moment, the only OS-dedicated
  > subdirs are config/msdos and config/winnt.  config/ itself is a
  > possibility; there is a very old nextstep.c already there.  I also
  > note a halfpic.c in the main dir for OSF's version, presumably
  > machopic could live there.  Finally, if necessary to conform to
  > policy, I could clone the code, one for each target; but that
  > seems undesirable.
  > 
  > Which way should I go?
I'd suggest in gcc/config/ or gcc/, similar to how we have files
that are shared across Linux on various chips, or *bsd*.


jeff