[Bug ld/27491] ld: relocation R_X86_64_PC32 against undefined protected symbol `__start_xx' can not be used when making a shared object

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=27491

--- Comment #5 from Fangrui Song <i at maskray dot me> ---
(In reply to H.J. Lu from comment #4)
> (In reply to Fangrui Song from comment #3)
> >
> > I don't know what happened to the 2010-01 patch. It likely did not let
> > __start_ reference retain magic sections in other translation unit (in
> > metadata section usage __start_/__stop_ references are always in a separate
> > runtime file), so "__start_ retaining all magic sections" was not effective
> > before 2015-10.  Why do we need new start/stop symbols? The orphan
> > __start_/__stop_ usage worked before 2015-10 and will work with -z
> > start-stop-gc.
> 
> You got it wrong.  --gc-section never worked correctly before all these
> fixed applied.

> > (I think of the possibility enabling -z start-stop-gc by default because the
> > rule was essentially invalid before 2015-10.)
> >
> 
> LLVM requires a different __start_/__stop_ semantic, which isn't wrong
> by itself.  But it shouldn't hijack the current one.

On Mach-O, ld64 define section$start$__DATA$__data and
section$end$__DATA$__data which are similar to the ELF encapsulation symbols
__start_/__stop_. ld64's behavior has always been similar to ld.lld -z
start-stop-gc.

Wow, really unfortunate that gold broke the nice GC semantics in 2010-01 and
GNU ld in 2015-10.
It'd be really nice to fix the issue as this made x86-64 -z start-stop-gc not
usable for -pie / -shared.

All of Clang PGO/SanitizerCoverage/source based Coverage documentation have
noted that --gc-sections may not work well <--- hope they can stop hinting the
users this way one day.

-- 
You are receiving this mail because:
You are on the CC list for the bug.