This is the mail archive of the
mailing list for the binutils project.
Re: sh64 partial link not resolving datalabel refs
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: "Clarke, Stephen" <stephen dot clarke at superh dot com>
- Cc: <binutils at sources dot redhat dot com>
- Date: Tue, 16 Jul 2002 21:18:39 -0400 (EDT)
- Subject: Re: sh64 partial link not resolving datalabel refs
On Tue, 16 Jul 2002, Clarke, Stephen wrote:
> We have a problem when trying to do a partial link for
> sh64 target.
> Here's a cut-down example:
A nice test-case. Ok to include it in the binutils testsuite?
(Got GNU binutils assignment papers in place? I can't check at
> The problem is that xxx remains undefined after the
> partial link, but it should have been pulled in from libx.a.
> The problem only occurs when the "datalabel" operator is used.
> I'd like to work out a fix for this, but I'm really
> not sure what to do: I can't see how this partial link
> behaviour is supposed to work.
The funny " DL" suffix was chosen for simplicity of debugging
and the " " avoids collision with real symbols; those are
placeholder symbols that never appear outside the bfd objects.
As the comments say, they are a means to keep STT_DATALABEL
stuck on the reference (and away from definitions) until the
final link: a datalabel reference and the actual symbol
definition are kept in separate bfd symbols. At the final link,
they are linked together by making the DATALABEL_SUFFIX symbol
an indirect symbol (an internal bfd feature) referring to the
real symbol (which might start out as an undefined symbol, but
with the right name). A datalabel reloc refers to this shadow
symbol. Remember from the spec: the datalabel qualifier
[implemented as the STT_DATALABEL ELF symbol qualifier], goes on
the *reference* never on the *definition*
> Any hints or ideas would be most welcome.
Just vague hints and mumbles; it was some time ago I wrote it.
One change that comes to mind is changing to
flagword flags = BSF_GLOBAL | BSF_INDIRECT;
(unconditionally; not BSF_GLOBAL for info->relocateable) in
sh64_elf_add_symbol_hook. Probably other tweaks are needed. Or
a fix in the machinery that resolves undefined symbols at -r; it
needs to know that it should pick objects from archives for
these datalabel references but not "link together" the symbols
(the datalabel reference and the found definition).
There's usually no problem with -r not linking together the
datalabel reference and a symbol definition; just that the
reference resolving is done at the final link (IIRC) rather than
during the -r.
Not setting flags |= BSF_INDIRECT (above) at -r, is IIRC
necessary to avoid having the indirection (and STT_DATALABEL)
peeled off before the final link; ld can't resolve it until the
code-ness is actually known. Unfortunately, in this case, as
you noticed, we need a "live" reference to pull an object with a
definition from an archive. Fix unknown. When fixing, need to
watch out that STT_DATALABEL isn't peeled of for datalabel
references that are still undef'd after the -r: they must retain
the datalabel qualifier after -r. (IIRC there are test-cases
for that.) And yes, this datalabel business *was* the trickiest
part of the sh64-elf binutils port. (Implementation caveat:
datalabel *must not* do an unconditional symbol_value&~1, it
must just avoid the symbol_value|1 that codelabel references do;
if the value is really non-even, then the datalabel qualifier on
the reference must not make it even.)