Why eh_frame sections in libgcc.a?

Why eh_frame sections in libgcc.a?

[Stefan Bylund]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

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? Is there support for
throwing C++ exceptions when dividing by zero? What happens with such support in
a plain C application? Are these ".eh_frame" sections in libgcc.a unused and
harmless when compiling a plain C application and linking it with libgcc.a?

/Stefan


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Card for Stefan Bylund --]
[-- Type: text/x-vcard; charset=us-ascii; name="steby.vcf", Size: 275 bytes --]

begin:vcard 
n:Bylund;Stefan
tel;cell:+46 709 714 325
tel;work:+46 8 507 143 25
x-mozilla-html:FALSE
url:http://www.ose.com
org:OSE Systems
adr:;;Nytorpsvägen 5;Täby;;183 23;Sweden
version:2.1
email;internet:steby@enea.se
title:Software Engineer
fn:Stefan Bylund
end:vcard

Why eh_frame sections in libgcc.a?

[Andrew Haley]

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.