Question regarding processing of .eh_frame sections during partial linking on elf64-ppc platforms

["William H. Maddox III" <maddox at transmeta dot com>]

Greetings.

I am developing a tool which transforms object files (.o -> .o),
performing non-trivial rewriting of the code appearing in the text
sections therein.  This tool is targetted to an elf64-ppc environment,
using an unreleased and lightly locally-modified version of ld 2.16.1 .

I am having difficulty in interpreting the contents of the .eh_frame
section in partially-linked (ld -r) output.  I am seeing relocations
for an FDE start PC that point to the single instance of a linkonce
section that is preserved, but which have ranges that indicate
that the FDEs arose from function instances in discarded sections.
(I have a check for FDE ranges that appear to extend beyond the end
of the function, and, for reasons that may reflect badly on the source
program, the like-named linkonce sections differ in length by a small
amount.)

The final link must recognize these garbage FDEs, and either remove
them, or arrange for the start PC to be zeroed out.  Apparently, an
"ld -r" will replace certain relocations pointing into a discarded
section with dummy relocations with a zero symbol index, which ultimately
results in zeroing out the relocated field.  I have observed this
occurring for the FDE start PC, but not in all cases.

I would not be at all surprised if there were simply a bug in "ld -r",
possibly a locally-introduced one, but I do not understand sufficiently
well how it is intended to work to make such a claim.  In particular,
from what I can glean from elflink.c, the test for an orphaned relocation
is much more complicated than a simple check for a zero symbol index.
There does not appear to be a clear specification anywhere of exactly what
"ld -r" does, such that a tool other than ld itself can make sense of the
result.

My question for the community is this:  Clearly, ld expects to be able
to produce a correct executable during the final link, in which the
.eh_tables are properly formed for interpretation at runtime.  It must
therefore be able to recognize stale FDE entries that apply to code
that has been discarded and does not appear in the executable.  How
are the stale FDEs recognized, given only the output of a prior partial
link?

More generally, I am interested in other quirks of "ld -r" where the
output of a partial link is of a form that could not arise as the
direct output of gcc, g++, or gas.

Note that I am not attempting to modify ld or any other part of
binutils, so my interest is not in the mechanics of how ld or binutils
is organized internally, but rather the specification, de jure or
de facto, for the object file transformation that "ld -r" performs.

Any explanation or pointers to relevant documents or prior discussions
would be most appreciated.

Thanks,


Bill Maddox