Here is the bug where elfhack was implemented. In the comments there is a link to a blog with details about it.
https://bugzilla.mozilla.org/show_bug.cgi?id=606145 On Fri, Oct 26, 2018 at 6:33 PM Bruce Dubbs via blfs-dev <blfs-dev@lists.linuxfromscratch.org> wrote: > > On 10/26/2018 05:54 PM, Ken Moffat via blfs-dev wrote: > > I'm slowly getting to a point where I've got the proposed changes > > for firefox ready (use clang, use gold, drop system icu). > > > > What initially concerns me is Douglas's (and fedora 29's) need to > > use --disable-elf-hack [ and I do not understand why fedora added a > > patch, if I use --disable-elfhack the configure stage quickly > > complains, but with --disable-elf-hack the log has no mentions of > > elfhack so it clearly did get disabled ]. > > > > Given that Douglas has had many problems on his new machine, I am > > tempted to say that his problem with python failing in the install > > seems to be unique to that machine. And for fedora's problems I can > > find no details of what architecture(s) were involved, nor how they > > failed. > > > > From what I can find, elfhack seems to be there to make libxul.so > > load faster - one report said it saved several hundred milliseconds > > and also saved several megabytes in the size of libxul.so. From > > that, I decided to do real installs of the different configs, and to > > see how long it took fo a killed firefox (from previous install) to > > be reloaded (libxul.so gets overwritten as part of the install). > > > > I clicked on the firefox menu entry as the seconds in the clock > > changed, and then after the *Sorry, we're having trouble ..." screen > > appeared I clicked on restore when the seconds changed. In all > > cases the times were "less than two seconds" and "about 1 second". > > Finally (the version without elfhack was installed) I rebooted, but > > this time I did not restore and instead went for a new session with > > just my home page. Again, the timings were similar. > > > > All the builds were on my haswell, from a term limited to 4 cores > > (4-7, the siblings of 0-3) and the system was otherwise mostly idle > > apart from xscreensaver. These are on 8.3, so I was initially using > > system ICU. The build with shipped ICU took a bit longer, and was a > > bit bigger - as expected - but what I did not expect was that > > disabling the elfhack would also take longer. However, these are > > all quicker than the 63.0b14 gcc build where I last used only 4 cores. > > > > The gcc build apparently used the bfd linker, with system icu, > > graphite2, harfbuzz. The other builds used clang, the gold linker, > > system graphite2 and harfbuzz. > > > > Type SBU Build dir Installed > > gcc 29.7 9.8 GB 141 MB > > clang 19.6 8.3 GB 142 MB > > + shipped icu 21.8 8.5 GB 155 MB > > + no elf hack 22.6 8.5 GB 162 MB > > > > My worry about disabling the elfhack is that (apart from fedora, > > whose problem might be on a different architecture), no other distro > > appears to need to do this. Therefore, I would prefer to keep it. > > > > More generally, as the pythonistas and rustaceans take over it seems > > that using system libraries is generally becoming harder (first sys > > cairo was dropped, now ICU needs a specific and not-latest version). > > > > I almost wonder if we should just drop system libraries and hope that > > mozilla will fix vulnerabilities in their shipped libs quickly, > > although past experience over the years suggests not. > > I think your approach is good. > > Just for info, I did a search for 'elf-hack' and the only place it > seemed to be used was in toolkit/moz.configure and that set a variable > USE_ELF_HACK. > > Searching for that, the only thing I found that seemed significant was > in build/unix/moz.build and that sets DIRS += ['elfhack']. > > From there I found build/unix/elfhack/elfhack.cpp > > Some of that is dedicated to specific architectures, but from what I can > tell it is an optimization of relocations when loading dynamic > libraries. However I could be completely wrong about that. > > Judging from your tests and what most of the main stream distros are > doing, I suggest we not mention the hack until we have a solid reason to > do so. > > -- Bruce > > > > > -- > http://lists.linuxfromscratch.org/listinfo/blfs-dev > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
