[oi-dev] I figured out exactly why Firefox and its forks can't link libxul.so with illumos LD.
Jeremy Andrews
athenian200 at outlook.com
Mon Aug 19 11:17:16 UTC 2019
I don't know if you guys would be interested in the details of this, but
I want to put them out there because I put a lot of research into this.
The fact is, the Firefox developers are actually messing with the
section attributes here, and it doesn't know what to do with illumos LD.
In fact, it comes packaged with a linker mapfile for GNU LD because the
trick they use only works with an obscure linker called gold, and pretty
much every other linker would need a mapfile to do what they want,
because it's really weird.
From the code itself:
"BFD ld doesn't create multiple PT_LOADs as usual when an unknown
section exists. Using an implicit linker script to make it fold that
section in .data.rel.ro makes it create multiple PT_LOADs. That implicit
linker script however makes gold misbehave, first because it doesn't
like that the linker script is given after crtbegin.o, and even past
that, replaces the default section rules with those from the script
instead of supplementing them. Which leads to a lib with a huge load of
sections."
And if I remove the mapfile, the GNU LD fails for the exact same reason
as illumos LD, and produces the same messed up results. Here's what the
GNU linker script looks like:
SECTIONS {
.data.rel.ro : {
*(.kPStaticModules)
}
}
So if my research is correct, what would need to be done if you want it
to work with the illumos LD is create a proper Solaris mapfile and use
that. I thought it might be a linker bug at first, but apparently not.
It's easy for someone to think it's either a linker bug or a library
bug, because all the errors appear in parts of the code relating to the
C runtime or libffi, and depending on where in the code the relocations
happen, you might get .eh_frame issues, but that's actually not the problem.
https://bugzilla.mozilla.org/show_bug.cgi?id=938437
This is where the change was made from static module registration to
some kind of linker hack that enables them to magically sort their
static modules in the correct order without having to maintain a
carefully constructed list.
https://github.com/bitwiseworks/mozilla-os2/issues/137
The guy porting Firefox to OS/2 did a better job of explaining precisely
what they did and how he was going to implement the same thing without
sections on his operating system. It pointed me in the right direction,
where I found this.
https://sourceware.org/gdb/onlinedocs/stabs/ELF-Linker-Relocation.html#ELF-Linker-Relocation
He provides two important pieces of information here. One is that GCC
doesn't output the symbols that the Sun linker requires to do to the
proper relocation of STABs in ELF format. The other is that on Solaris,
people have been known to use a zero value to get the address from ELF
symbols. And if you look at this official Solaris Firefox repository,
you'll see they have this:
https://github.com/oracle/solaris-userland/blob/82dd4adb0eca729372074d62435e00a783d95b1f/components/desktop/firefox/patches/firefox-41-static-xul-components.patch
It uses the exact hack described in the Sourceware article earlier,
using a zero value to get the address from ELF symbols. However, this
apparently cannot be done on illumos because, as they've stated, GCC
doesn't output the symbols that the linker requires in order to do it.
In fact, compilation fails entirely if you try that patch on OI, but
presumably it works on the Sun compiler/linker combination.
So, it seems like the reason this problem is so intractable is because
the illumos linker (assuming it's still similar to the Sun linker)
relocates stabs based on ELF symbols that it expects the compiler to
provide, while GCC relies on the linker to relocate stabs and doesn't
provide those symbols. So basically, on OI, we would appear to be stuck
with a situation where it is difficult or impossible to relocate stabs
in an automated and orderly fashion because the linker and the compiler
don't "speak the same language."
This may not be news to anyone here, but I just learned about all of
this stuff very recently and I have no background in understanding ELF,
linkers, STABs, or any of that stuff prior to this.
More information about the oi-dev
mailing list