PATCH COMMITTED: Fix mix of read-only/read-write .eh_frame sections

[Ian Lance Taylor]

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>