This is 5% faster on my setup, mostly thanks to unrolling being
possible.
We also skip the early loop exit. Most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations if we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
This is 20% faster on my setup, and according to llvm-mca, the IPC for
the false branch (which is the hottest one) goes from 3 to 5.7, thanks
to unrolling and conditional moves.
Only activated on non-Android target though, as it breaks at runtime.
Basically, most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations as we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
This is 20% faster on my setup, and according to llvm-mca, the IPC for
the false branch (which is the hottest one) goes from 3 to 5.7, thanks
to unrolling and conditional moves.
Basically, most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations as we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
This is 20% faster on my setup, and according to llvm-mca, the IPC for
the false branch (which is the hottest one) goes from 3 to 5.7, thanks
to unrolling and conditional moves.
Basically, most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations as we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
This is 20% faster on my setup, and according to llvm-mca, the IPC for
the false branch (which is the hottest one) goes from 3 to 5.7, thanks
to unrolling and conditional moves.
Basically, most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations as we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
When the injected code is used by elfhack, the debug info is thrown away
because elfhack doesn't know what to do with it, but in the case of
relrhack, the normal linker can handle it, so there's no reason not to
include the debug info anymore.
Differential Revision: https://phabricator.services.mozilla.com/D192904
When .rel.plt and .relr.dyn are the same size, after the section header
for .relr.dyn has been updated, it matches the condition for .rel.plt,
and we ended up undoing the change.
Differential Revision: https://phabricator.services.mozilla.com/D192981
On ARM, lld places the .ARM.exidx section between .rel.dyn/.relr.dyn and
.rel.plt. This means we can't swap .relr.dyn and .rel.plt (well, we
could, if we also moved and rewrote the .ARM.exidx section, but that's
more work than we ought to do).
But we only need to swap the sections when we want the binary to be
compatible with older versions of glibc, which we don't care about on
desktop ARM Linux (we don't ship such builds), and don't need at all
on ARM Android. Ultimately, this is a bug in lld
(https://github.com/llvm/llvm-project/issues/68178).
Differential Revision: https://phabricator.services.mozilla.com/D190006
Old versions of llvm-readelf didn't have parens in its output for `-d`.
So instead of looking for parens, look for word boundaries.
Differential Revision: https://phabricator.services.mozilla.com/D188897
Elfhack is the main reason we're not using lld on Linux/Android
shippable builds, because the way it works doesn't go well with how lld
lays out ELF binaries. By leveraging the linker itself (BFD and lld both
having recently gained the ability to generate the compact relocation
info themselves), we can achieve a similar result to what elfhack is
doing, while allowing to use lld.
See more in-depth background on https://glandium.org/blog/?p=4297
Differential Revision: https://phabricator.services.mozilla.com/D187089
Elfhack acts as a linker, and it uses the `elf_header` symbol to point
at the ELF header in the injected code that applies relocations.
Both GNU ld and lld expose a `__ehdr_start` symbol with the same meaning,
so rename the `elf_header` symbol for compatibility. This will allow to
reuse the code in the upcoming replacement for elfhack.
Differential Revision: https://phabricator.services.mozilla.com/D187088
Because it bumps the alignment requirement on aarch64, we make the
elfhack test create more relocations to make the .rela.dyn section large
enough for the test to pass.
Differential Revision: https://phabricator.services.mozilla.com/D181684
I'm pretty sure there are other theoretical problems in the code,
notably when a single section is larger than 4GB, but by the time
we reach that limit, bug 1839740 will have been fixed.
Differential Revision: https://phabricator.services.mozilla.com/D182447
Bug 1747782 changed the format to SHT_RELR, but what's produced is still
different from a real SHT_RELR section, because it uses a terminating
nul entry.
Differential Revision: https://phabricator.services.mozilla.com/D181689
For a few NDK releases now, the situation has been simplified wrt
headers and libraries, and while we're currently still using things here
and there because we never changed our ways, we can simplify things a
lot by using the new simplified things. This involves:
- Using a --target that contains the Android version, making clang set
__ANDROID_API__ itself, and makes it look in $sysroot/usr/lib/$target/$ver
when linking.
- Using the sysroot that is under toolchains/llvm/prebuilt/*.
- Removing the hacks around libstdc++/libc++.
This ends up emptying stlport compiler flags, which allows to remove a
bunch of things.
Differential Revision: https://phabricator.services.mozilla.com/D172039
For a few NDK releases now, the situation has been simplified wrt
headers and libraries, and while we're currently still using things here
and there because we never changed our ways, we can simplify things a
lot by using the new simplified things. This involves:
- Using a --target that contains the Android version, making clang set
__ANDROID_API__ itself, and makes it look in $sysroot/usr/lib/$target/$ver
when linking.
- Using the sysroot that is under toolchains/llvm/prebuilt/*.
- Removing the hacks around libstdc++/libc++.
This ends up emptying stlport compiler flags, which allows to remove a
bunch of things.
Differential Revision: https://phabricator.services.mozilla.com/D172039
Use the SHT_RELR format which significantly improves the size reduction
from elfhack:
total size of .rel.* + .elfhack.* sections
x86 x86_64 android-arm
plain 3532904 10739544 3488888
current-elfhack 1085815 1155994 1042048
relr-elfhack 130219 193552 113840
Differential Revision: https://phabricator.services.mozilla.com/D134756
Elfhack currently can't deal with files larger than 4GiB because it
translates all ELF data structures to the 32-bits variant, even for
64-bits ELF files. So if the original file has e.g. sections that start
after the 4GiB boundary, they can't be represented in memory.
Practically speaking, this is not causing problems, but has prevented a
working elfhack for aarch64 because e.g. some relocation types don't fit
in the 32-bits ELF representation.
Differential Revision: https://phabricator.services.mozilla.com/D134745
