On Tue, Apr 25, 2006 at 09:17:01AM +0100, Derek Fawcus wrote:
> On Mon, Apr 24, 2006 at 08:51:17PM -0700, Roman Shaposhnick wrote:
> > On Tue, Apr 25, 2006 at 03:37:04AM +0100, Derek Fawcus wrote:
> > > > Well, this is to unwind trough exceptions through the C stack:
> > >
> > > There is no c++ code here, last I looked there is no c++ in dietlibc.
> >
> > That's the beauty of a shared library
>
> Well it must be junk in the linker script, I just can't be bothered to
> track it down and fix it. This section is not in the .o; and the output
> was a static file. So there is no call for the .eh_frame as this is not
> an AMD64 - it is a plain old 32 bit x86.
You can call it whatever you want. I explained the reasons it is there.
On top of which I can add that it *is* helpful to have .eh_frame if
any of your callers can be C++. Since I don't understand what part of the
explanation you don't understand the last thing I can add to this
conversation is that there are 2 kind of exception related sections
generate by two different components:
* .eh_frame is generate by the compiler (and these days even by the
C compiler running on arcs which don't strictly require it) and has
tables describing the stack layout and such. It is actually based
on DWARF2 and is rather difficult to get rid of, unless you want
to write linker scripts or use objcopy.
* .eh_frame_hdr is generated by the GNU ld when it sees --eh-frame-hdr
and has index for facilitating binary searches inside the actual
.eh_frame sections. This one you can skip by making sure GNU ld
is not given --eh-frame-hdr.
Thanks,
Roman.
