This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- From: Michael Matz <matz at suse dot de>
- To: Cary Coutant <ccoutant at gmail dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Thu, 25 Feb 2016 14:27:59 +0100 (CET)
- Subject: Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- Authentication-results: sourceware.org; auth=none
- References: <20160223175814 dot GA2858 at intel dot com> <alpine dot LSU dot 2 dot 20 dot 1602241541430 dot 20277 at wotan dot suse dot de> <CAMe9rOoxU43=dhGYZZGQtWhfbU-sGRoaiiJ7PfPNtzSc05-t-A at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241552020 dot 20277 at wotan dot suse dot de> <CAMe9rOpEWKVVP=-o0t0emkjKR0-xqnn-YZ5C5nfa=0E4BkEZaw at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241709410 dot 20277 at wotan dot suse dot de> <CAMe9rOr5qa_PBJA3oDENWErRfrojtzC1ncXaWwyh-1EAczPn-g at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241749340 dot 20277 at wotan dot suse dot de> <CAMe9rOrSNYV_x-5aU7K+hXHNrinE9Co8y1F5VUkY+SoRQize=g at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241753490 dot 20277 at wotan dot suse dot de> <CAMe9rOpZNHtKRvx+5QurEOcVU96WEQuBRPJ6UorocjE-8Jd+vQ at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241808400 dot 20277 at wotan dot suse dot de> <CAMe9rOpAkC238Gvji0rf1_wBqEAZDDeTkhp_o-BirUrTa622aA at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241843180 dot 20277 at wotan dot suse dot de> <CAJimCsG=1u_yM6SBFAxCxB4JvWtxO5fZ22+OmG6UC_RYON3DdA at mail dot gmail dot com>
On Wed, 24 Feb 2016, Cary Coutant wrote:
> FWIW, gold used to leave references to weak undefs for the dynamic
> loader to resolve.
And it still does:
% cat try.c
extern int __attribute__ ((weak)) printme (void);
extern int __attribute__ ((weak)) undefed;
% gcc -c -fpic try.c
% gcc -v -o try try.c
% gold/ld-new $(args_from_gcc_v_link)
% readelf -r try
Relocation section '.rela.dyn' at offset 0x420 contains 3 entries:
Offset Info Type Sym. Value Sym. Name +
0000004019b0 000200000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
0000004019b8 000600000006 R_X86_64_GLOB_DAT 0000000000000000 printme + 0
0000004019c0 000700000006 R_X86_64_GLOB_DAT 0000000000000000 undefed + 0
Relocation section '.rela.plt' at offset 0x468 contains 3 entries:
Offset Info Type Sym. Value Sym. Name +
0000004019e0 000100000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_main + 0
0000004019e8 000200000007 R_X86_64_JUMP_SLO 0000000000000000 __gmon_start__ + 0
0000004019f0 000600000007 R_X86_64_JUMP_SLO 0000000000000000 printme + 0
You changed gold behaviour only for non-PIC code (where GNU ld indeed
doesn't emit dynamic relocs, this discrepancy is exactly what this whole
thread is about), not generally.
> We got complaints, and changed it to match gnu ld's
> I'd prefer not to change ld after having already changed gold to match
> -- especially so when that change was motivated by user complaints.
> Daniel replied to the first of the above messages, suggesting that the
> existing ld behavior was surprising, and I agreed. Ian's response was:
Rereading that thread it's actually the GNU ld behaviour (_not_ emitting a
dynamic reloc for weak symbols) that Daniel found surprising (at least
that's how I read it). Downthread Alan made an argument for why dynamic
relocs are really the right thing,
and even further downthread the problems with that approach were clarified
So, GNU ld and gold do emit dynamic relocs under the right circumstances
right now (which IMHO is the right thing), and that fact ...
> > Based on this discussion, I think we should go ahead and commit this
> > to gold. It makes gold act like GNU ld. Clearly more thought is
> > required before changing the linker behaviour in this area.
> I suppose this thread can be considered "more thought", but it hasn't
> swayed me. We've had eight more years worth of installed base using the
> current behavior since that discussion.
... should hold for this as well. It's old behaviour, we always did this.
I don't think it's appropriate to change it (no matter what we think is
the right or wrong behaviour).