This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Hello Alan,

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 common code.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]