Re: [PATCH] bfd: Mark symbols with mismatching types

[Egeyar Bagcioglu <egeyar dot bagcioglu at oracle dot com>]

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
> > linker.
> 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.

Thanks,
Egeyar