[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