This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Exceptions workaround for older systems that don't USE_COLLECT2


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
> magic.

You're right.

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
section support.

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
section.

If no one tells me why I shouldn't, I'll build a EGCS 1.1 variant that
supports this strategy this weekend...

    Melissa.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]