Re: spliting up libgcc2.c

[Jeffrey A Law <law at cygnus dot com>]

  In message <199912071625.aa06245@gremlin-relay.ics.uci.edu>you write:
  > Some time ago Jeff Law said that libgcc2.c should be split up in
  > smaller files, so we dont' have to do all that #define  ahckery when
  > building libgcc.a (and possibly other reasons).
  > 
  > I have done this, created a new directory libgcc and put splited files
  > in there. 
  > 
  > There are some issues that people might want to think about: 
  > 
  > - the functions in libgcc*.c are of 2 kinds: some use the normal C
  >   types, some use the [IQFT]Mode types. 
  >   I have created 2 header files that contain the typedefs for each
  >   cathegory, and individual files only inclde the header that it
  >   needs. 
  > 
  >   I called them modetypes.h and  normtypes.h 
  >   Suggestions for better names are welcome. 
  > 
  > 
  > - I also created a perform-op.h file that contains the perform_*
  >   defines used in libgcc1.c
  > 
  > - negdi () and udivmoddi4 () were defined in their own object file, but
  >   also as inlines in other places that use them. 
  >   I created negdi2.h   and udivmoddi4.h that contain the definition of
  >   these functions, they are included in the files that need to have
  >   those functions inlined. 
  > 
  >   negdi2.c   and udivmoddi4.c just include the corresponding header. 
  > 
  >   If you can think of a better solution for this please tell me...
  > 
  > - I also created a clz_tab.h file, but I see not that the array that
  >   is defined there is not used anywhere, so this one will disapear. 
  > 
  > 
  > What I didn't do is to write the Makefile hackery to allow libgcc.a to
  > be built from these files.  I don't understand the build mechanism
  > well enough to be able to do this. 
  > Robert Lipe said he will try to do it, but he seems to be busy at the
  > moment, so if somebody else wants to step up, it will be very
  > welcome. 
  > 
  > The starting point for this work was the 10/27 gcc snapshot. After I
  > get some feedback I will update to a newer version. 
Cool.  rth & I talked about this some a month or two ago and the biggest
issue I remember from that conversation was the need for the ability for
a target to override the default sizes of some of the types.  Or better
yet, a way for the target to say "I don't want any DImode, or DFmode stuff)".

Right now that's done via truly gross -D arguments (see 
config/mn10200/t-mn10200
for an example.

I wouldn't worry about preserving the existing build mechanisms -- this
will always be compiled by gcc, so we know -o filename.o works.  So just
build each component into a unique blah.o and use ar to put them together.

The other potential issue I see is do we have any targets which are still
using libgcc1?  If so, we'll need some way to combine the libgcc1 components.

jeff