1485562 - elfhack busts libnss built with clang+lto

Status: RESOLVED DUPLICATE of bug 1079662

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

Not sure what's wrong yet, but the result is crashes while running certutil.

Comment 1

[Mike Hommey [:glandium]]

So what's happening is that enabling LTO with lld changes some relocations in the certutil binary from:
   R_X86_64_GLOB_DAT
to
   R_X86_64_COPY

meaning, the data actually ends up duplicated at runtime by the dynamic linker, instead of pointing to the data in shared library. The problem is that for some of those, the data is relocated. Without elfhack, everything goes fine, because the dynamic linker does the data copy after it applies relocations, but with elfhack, the relocations happen when running the elfhack code, which doesn't happen until static initialization, and the dynamic linker doesn't run static initialization before processing those relocations.

I know that what elfhack does is, as its name indicates, very hacky, but I have doubts about using COPY relocations by lld being right here. I'll have to dig on the lld side to see whether it's doing something wrong or if elfhack should avoid touching relocations in public symbols.

Comment 2

[Mike Hommey [:glandium]]

Presumably, it does that because the symbols are in .data.rel.ro, and that's valid in that case. Although it's weird that it does that with LTO but doesn't without...

Comment 3

[Mike Hommey [:glandium]]

So, it seems that lld LTO compiles code as non-PIC when building an executable that is not PIE. Which is a difference from non-LTO, where the objects are still built PIC and linked together. That's why it ends up using COPY relocations with LTO and not without.
Considering how generally bad the copy relocations are, I think we should add -z nocopyreloc to the linker flags in the first place... and figure out how to build PIC code on non PIE executables. Or bite the bullet and figure out how to ship Firefox as PIE (bug 1079662)