(6/6): i386-pc-interix support -- gcc

[Jeffrey A Law]

  In message < 36F6754F.92537D4B@interix.com >you write:
  > (Is "one" here referring to the specific item above, or to the whole patch?
  > I'm presuming the latter in this response.)
The whole patch.

Consider that most of the basic files are non-controversial.  We could
have installed them some time ago.  But since they were bundled with
other patches which probably do need some work, they were put near
the bottom of my queue.

  > This is a tricky interaction with ld having to do with placing the
  > ___CTOR_LIST___ and ___DTOR_LIST___ symbols correctly in the PE
  > environment along with some other changes that are not yet
  > submitted.  This change can be reasonably deferred until the rest
  > of the package comes along, if that makes life simpler.
Let's defer it temporarily and come back to it later.  When that
happens I'll want additional technical info describing why none of our
existing mechanisms work.

  > It also runs on the Alpha;
Ok.  Thanks.


  >  above you indicated a preference for bite-sized
  > chunks, and holding the Alpha until later was for exactly that reason.
Yup.  That's the right thing to do.

  > >   >     * i386/i386.c (load_pic_register): Use __GLOBAL_OFFSET_TABLE on
  > >   >     Interix.
  > >   >     * i386/i386.md (prologue_get_pc_and_set_got): Likewise.
  > 
  > This is an Alpha interaction (Alpha on NT doesn't use the leading
  > underscore convention). Can defer until it forces the issue, but
  > alternatives welcome.
Instead of using 
#ifdef INTERIX
blah blah
#endif

Create a definition for the name of the GOT variable and use it in
i386.c and i386.md.  Then provide an override in interix.h.  That way
we avoid infesting the generic i386 files with system specific
#ifdefs.


  > >   >     * gcc.c (main): Add specs handling for environment variables.
  > >   >     Add $INTERIX_ROOT/usr/lib/ etc to startfiles_prefixes.
  > 
  > Interix specific and guarded.
Not acceptable.  We don't want to put those kinds of ifdefs into
generic code if we can avoid it.  You need to look for a cleaner way
to address this issue.


  > >   >
  > >   >     * sdbout.c (syms.h): Don't include on Interix.
  > >   >
  > >   >     * protoize.c (abspath): Preserve multiple leading slashes.
  > >   >
  > >   >     * toplev.c (main): No sbrk on Interix.
  > >   >
  > >   >     * c-parse.y (absdcl1): Allow attributes in explicit typespecs.
  > >   >     (%expect): Update.
  > >   >     * c-parse.h: Regenerate.
  > >   >     * c-parse.c: Likewise.
  > > We'll resolve these once we've resolved the basic config patches.  We
  > > should go after them one by one.
  > 
  > I presume you'd like the ones between sdbout and c-parse.c as separate
  > chunks.
Actually, each should be a separate patch since each addresses an
independent issue.

  > Specifically what action is required at this time?  Are you going to apply
  > the easy ones above, or do you need a new bundle with just those, plus
  > a series of smaller patches for the more controversial ones?  (Just so we
  > know precisely what you require.)
I took care of the basic config files.   I'm going to look at some of
the other changes.

Basically, I'm going to resolve those which don't need reworking or
additional explanation.  Then we'll need to iterate on the remaining
changes.

We already know that the gcc.c & i386.c/i386.md changes need some
additional work.  You should deal with the needed changes to gcc.c 
and i386.c/i386.md and resend those patches (separately).

jeff