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
serge-sans-paille
Mike Hommey
Natalia Csoregi
Cristian Tuns
Norisz Fay
Cosmin Sabou
Narcis Beleuzu
Sandor Molnar
Logan Rosen
Ryan VanderMeulen
Stanca Serban