This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- From: Cary Coutant <ccoutant at google dot com>
- To: Cary Coutant <ccoutant at google dot com>, Binutils <binutils at sourceware dot org>, Ian Lance Taylor <iant at google dot com>, Jing Yu <jingyu at google dot com>, Han Shen <shenhan at google dot com>, Doug Kwan <dougkwan at google dot com>, David Miller <davem at davemloft dot net>
- Date: Thu, 18 Dec 2014 15:40:41 -0800
- Subject: Re: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- Authentication-results: sourceware.org; auth=none
- References: <CAHACq4oi4UT7LLv-vz5+ocpkPU8zwtyOQ8Gas_S3WdB_7WgN2w at mail dot gmail dot com> <20141218224458 dot GC31055 at bubble dot grove dot modra dot org>
> As the comment says it "could reasonably be the case for a weak
> undefined symbol". If the reference to a weak symbol is in PIC, then
> you can emit dynamic relocs and have an executable do something
> reasonable based on whether the symbol is defined at runtime.
With my patch, I get an internal error for the unresolved TLS symbol
when trying to apply a (PIC) R_X86_64_TLSGD relocation.
For PIC code, Gnu ld will generate dynamic relocations for a non-TLS
symbol or function symbol, but not for a TLS symbol. Is that a bug, or
behavior that gold should match?
So, yeah, it looks like the expected behavior depends on the
relocation, so patching it in target-independent code isn't going to
work (unless I pass an is_pic_relocation flag to
final_value_is_known()).
Making the symbols weak vs. using --warn-unresolved-symbols doesn't
seem to make a difference -- Either way, Gnu ld will statically
resolve non-PIC references to 0, and will make dynamic relocs for PIC
non-TLS references.
-cary