This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Why eh_frame sections in libgcc.a?
- From: Andrew Haley <aph at redhat dot com>
- To: Stefan Bylund <steby at enea dot se>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 11 Oct 2002 13:21:31 +0100 (BST)
- Subject: Why eh_frame sections in libgcc.a?
- References: <3DA6A629.35A52EDD@enea.se>
Stefan Bylund writes:
> When building GCC 3.2 for powerpc-eabi, ".eh_frame" exception handling sections
> are generated in libgcc.a for the following objects:
>
> _divdi3.o
> _moddi3.o
> _udivdi3.o
> _umoddi3.o
> _udiv_w_sdiv.o
> _udivmoddi4.o
> unwind-dw2.o
> unwind-dw2-fde.o
>
> I can understand why such sections are generated for unwind-dw2.o and
> unwind-dw2-fde.o which are used by libstdc++.a and libsupc++.a but why are they
> generated for the other integer division related objects?
Because Java throws an exception on division by zero.
> Is there support for throwing C++ exceptions when dividing by zero?
You'll need -fnon-call-exceptions to make this work. You'll also need
some code to trap the signal and trun it into an exception; examples
are in libgcj. This does not work on all platforms.
> What happens with such support in a plain C application?
It's irrelevant unless an application catches the signal and throws an
exception. Plain old C can make a signal handler and longjmp() out of
it.
> Are these ".eh_frame" sections in libgcc.a unused and harmless when
> compiling a plain C application and linking it with libgcc.a?
Yes.
Andrew.