This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] bfd: Mark symbols with mismatching types
On 04/14/2017 01:27 AM, Alan Modra wrote:
On Wed, Apr 12, 2017 at 10:11:42PM -0700, Egeyar Bagcioglu wrote:
Introduce flag for defined symbols whose type is mismatched with a
dynamic definition. Mark such symbols. Prevent such symbols from being
made dynamic in sparc.
Sparc makes use of dynamic symbols during relocations. Unless detected,
above-mentioned symbols are confused with library symbols by the dynamic
Please provide a C testcase. I can see what you're trying to prevent
but the testcase I wrote to investigate the problem on sparc and other
targets does not result in bad dynamic symbols, even though the linker
does hit the code where you are setting conflict_with_library.
Obviously I'm missing some detail.
A testcase is necessary to prove that you really do need a new flag in
elf_link_hash_entry. If the problem only shows up on sparc, then a
different fix in the sparc backend is likely better. If the problem
is generic then yes, we may need a new flag, but even then there is
likely a better fix.. I'm not asking for a patch that integrates a
test into the ld testsuite, just a set of C files and gcc command
lines to build it.
There is already a failing test case due to this problem. You can see
"FAIL: Run pr2404 with PIE" when running ld-elf/shared.exp on sparc. The
test is for the specific case of having conflicting symbols.
'_bfd_elf_merge_symbol' currently just skips the merge of such symbols
without any further action.
However, on sparc backend, we take the liberty of making some symbols
dynamic while adjusting and optimizing relocations. This is becoming a
problem in case of such conflicting symbols. A call to a library
function is causing dynamic linker to see the symbol (of a variable) in
the executable. The dynamic linker assumes versionless symbol for the
variable is the first version of the function that it is looking for.
As the sparc backend works as intended for all other symbols, I would
like to change the treatment of only this case that is already detected
in the common code (elflink.c). It would be expensive to re-detect such
interference between symbols in sparc backend: We would need to run each
symbol against the hash table. Such an act would be redundant and have a
high complexity. Therefore, we need to somehow mark such symbols in the
If your hesitation is regarding adding another flag, I can suggest using
the "forced_local" flag. This might be acceptable too, because such
symbols being dynamic would affect the dynamic linker in other
architectures as well.
If you have any other suggestions, I am open to discuss and learn.