Constructor order help (related to PR 6482)

[Kean Johnston]

> Ok, the first thing I'd like to do is to split crtstuff.c
> into multiple files.
Ok I'll start getting to grips with it.

> Step two I'm less certain about, but at present I'm thinking
> that it might be cleaner to move the choice of which crtbe-*.c
> file to use from the ifdef madness that will remain in 
> crtstuff.c into explicit assignments in config.gcc.
You're right, it would be cleaner to explicitly set it either
in config.gcc or even in the target's header file. Perhaps a
two-phased approach is best. First split the beast up, leaving
the pre-processor conditionals in crtstuff, then do step three,
the DT_INIT_ARRAY code, then once that's all nice and wrapped
up, then go back and do a final cleanup of crtstuff.c

Actually the more I think about it the more I think that chosing
the mechanism should be left to the target header file and not
config.gcc. I bet you anything that some exotic host somewhere
is going to need the power of the pre-processor in its own files
to decide on the mechanism. Heck, if I was still doing COFF
stuff in sco5.h, I would need to have it there, and select the
mechanism based on the -melf/-mcoff flag. Someone, someday, is
going to want to do it there so we may as well put it in the
target files from the get-go. Which means that that step should
be last, because it is more invasive. It will require a lof of
files change and a lot of testing be done.

> > *LONG* gone :) I will drag openserver kicking and screaming
> > into the early 90's if it kills me :)
> 
> I'll look forward to seeing those patches.
I am busy cleaning all this stuff up. I just found a linker option
that fixes a few interesting test failures. gcc.dg/special/weak*
have always failed on OSR5, and yet, #pragma weak sym = othersym
has always worked (the mor traditional way of doing weak symbols).
But now I found an option that allows attribue(weak) to work too.
So I'll add that to the LINK_SPEC and forge ahead. I got a lot
of failures after removing {C,D}TORS_SECTION_ASM_OP along the
lines of "COMPILER_PATH: not an identifier" during g++ tests
so I am chasing that down. But gcc itself is looking better.
Only 8 failures and 3 of those I suspect will go when I use
-z alt_resolve (that's the linker flag to fix .weak stuff).

> I suspect that gcc bug is still there.  We should fix it somehow.
The GCC bug is fixed, and HJ pointd out that it is in binutils
modern too. I was looking at 2.13.2.1, the one on gnu.org. The
more moderns snapshorts do the right thing, he tells me.

Kean