Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable

[Michael Matz <matz at suse dot de>]

Hi,

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;
int
main (void)
{
  if (printme)
    printme ();
  if (&undefed)
    return 0;
  return 1;
}
% 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 + 
Addend
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 + 
Addend
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
> behavior:
> 
> https://sourceware.org/ml/binutils/2008-04/msg00019.html
> 
> https://sourceware.org/ml/binutils/2008-04/msg00269.html
> 
> 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,

  https://sourceware.org/ml/binutils/2008-04/msg00025.html

and even further downthread the problems with that approach were clarified

  https://sourceware.org/ml/binutils/2008-04/msg00032.html
  https://sourceware.org/ml/binutils/2008-04/msg00051.html

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


Ciao,
Michael.