PATCH COMMITTED: Fix mix of read-only/read-write .eh_frame sections
Ian Lance Taylor
iant@google.com
Wed Apr 9 00:32:00 GMT 2008
Normally gold does not combine read-only and read-write sections with
the same name. This is different from GNU ld's behaviour. However,
gcc relies on this merging when generating the .eh_frame section. gcc
has a configure test for whether read-only and read-write sections are
merged; when they are merged, it emits read-only .eh_frame sections
when possible, read-write .eh-frame sections when necessary, in the
hopes that all the .eh_frame sections in a specific link will be
read-only. Since existing gcc binaries have this behaviour, gold has
a special exception for merging read-only and read-write .eh_frame
sections.
However, this failed to correctly handle the case of an empty
read-write .eh_frame section. Handling this case correctly is
required to make a static link work with some configurations of gcc.
I committed this patch to fix this. Basically we just make sure that
we add the merge .eh_frame sections in the right place with respect to
unmerged .eh_frame sections.
Ian
2008-04-08 Ian Lance Taylor <iant@google.com>
* layout.h (class Layout): Add added_eh_frame_data_ field.
* layout.cc (Layout::Layout): Initialize new field.
(Layout::layout_eh_frame): Don't add eh_frame_data_ to .eh_frame
output section until we find a section we merged successfully.
* object.cc (Sized_relobj::check_eh_frame_flags): Don't require
that the size be non-zero.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.patch
Type: text/x-patch
Size: 3167 bytes
Desc: Fix mix of read-only/read-write .eh_frame sections
URL: <https://sourceware.org/pipermail/binutils/attachments/20080409/193d9196/attachment.bin>
More information about the Binutils
mailing list