From: Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] bfd: Mark symbols with mismatching types
Date: Fri, 14 Apr 2017 14:57:00 -0000 [thread overview]
Message-ID: <b8163a34-9e2e-e306-55ff-23b86ff59699@oracle.com> (raw)
In-Reply-To: <20170413232700.GU24006@bubble.grove.modra.org>
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
next prev parent reply other threads:[~2017-04-14 14:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 13:13 Egeyar Bagcioglu
2017-04-13 23:27 ` Alan Modra
2017-04-14 14:57 ` Egeyar Bagcioglu [this message]
2017-04-16 6:26 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8163a34-9e2e-e306-55ff-23b86ff59699@oracle.com \
--to=egeyar.bagcioglu@oracle.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).