This is the mail archive of the
mailing list for the GCC project.
Re: Exceptions workaround for older systems that don't USE_COLLECT2
- To: Jason Merrill <jason at cygnus dot com>
- Subject: Re: Exceptions workaround for older systems that don't USE_COLLECT2
- From: "Melissa O'Neill" <oneill at cs dot sfu dot ca>
- Date: Sat, 19 Sep 1998 00:07:18 -0700
- cc: law at cygnus dot com, egcs at cygnus dot com, egcs-patches at cygnus dot com, Jamie Lokier<egcs at tantalophile dot demon dot co dot uk>
- References: <email@example.com><199809161633.JAA03142@aldrington.ppp.cs.sfu.ca><firstname.lastname@example.org>
Jason Merril writes:
> I notice that the header talks about constructor_section(); if the target
> supports named sections, you could use crtstuff instead of any linker
I think we can use named sections, and certainly if we can, we should
to avoid the slowness of collect2. Enabling collect2 was Jeff Law's
suggestion, and knowing little about the internals at the time, I accepted
the fix (as time goes by, I seem to be learning more and more about how
these things work, and so my viewpoint is getting clearer).
I think the situation under NEXTSTEP a little different from other
platforms though, since NEXTSTEP's own crt0.o (and system library)
support the .ctors and .dtors sections themselves, we only need to
provide support for exceptions. Also, while the NEXTSTEP's Mach-O format
does understand named sections, the runtime system does not provide init
Given these points, the easiest way to support exception handling would
be to provide a crtbegin.o which provided a frame registration function,
and mentioned that function in the .ctor section, and a crtend.o that
provided a frame deregistration function and declared it in the .dtor
If no one tells me why I shouldn't, I'll build a EGCS 1.1 variant that
supports this strategy this weekend...
P.S. I could do my changes for the current egcs snapshot, but I like to
work on a base I know to be robust, so that I know any problems are mine.