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
Aliased commands have not loaded the virtualenv associated with a
command/subcommand since bug 1695312. It has been defaulting to the
`common` virtualenv, which worked most of the time since most commands
use `common` and it also contains a large share of our dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D192376
`--enable-phc` builds firefox with PHC support. It's not enabled unless the
`phc` pref is also set. So this change will cause PHC support to ride the
trains, but in a disabled state.
Differential Revision: https://phabricator.services.mozilla.com/D188821
Some more recent fixes upstream unbroke cross-compiling the windows
compiler-rt, so we don't need the reversal patch anymore. We also don't
need it on clang 14 either because we don't build the windows
compiler-rt there.
Differential Revision: https://phabricator.services.mozilla.com/D189881
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
Setting them before the first call to check_compiler can fail when the
compiler doesn't recognize the flag for its default target and actively
errors out.
Differential Revision: https://phabricator.services.mozilla.com/D189861
Sprinter::jsprintf is nowadays the same as GenericPrinter::printf which Sprinter
inherit from. This patch removes all calls to Sprinter::jsprintf and replaces
them by Sprinter::printf.
The advantage of using GenericPrinter::printf is that this reduce the dependency
on Sprinter-specific interface and moves us toward being able to move more
consumers over to the GenericPrinter.
Differential Revision: https://phabricator.services.mozilla.com/D181500
The patch it reverted was causing problems while running tests with
ASan, but, from a try push, it seems those are not happening anymore.
Presumably, the issue was either fixed on the workers (whatever that
might have been), or in newer versions of clang.
Either way, we're not using clang 14 for ASan builds either, so we can
remove the patch from clang 14 too.
Differential Revision: https://phabricator.services.mozilla.com/D189908
The patch it reverted was causing problems while running tests with
ASan, but, from a try push, it seems those are not happening anymore.
Presumably, the issue was either fixed on the workers (whatever that
might have been), or in newer versions of clang.
Either way, we're not using clang 14 for ASan builds either, so we can
remove the patch from clang 14 too.
Differential Revision: https://phabricator.services.mozilla.com/D189908
Some more recent fixes upstream unbroke cross-compiling the windows
compiler-rt, so we don't need the reversal patch anymore. We also don't
need it on clang 14 either because we don't build the windows
compiler-rt there.
Differential Revision: https://phabricator.services.mozilla.com/D189881
Sprinter::jsprintf is nowadays the same as GenericPrinter::printf which Sprinter
inherit from. This patch removes all calls to Sprinter::jsprintf and replaces
them by Sprinter::printf.
The advantage of using GenericPrinter::printf is that this reduce the dependency
on Sprinter-specific interface and moves us toward being able to move more
consumers over to the GenericPrinter.
Differential Revision: https://phabricator.services.mozilla.com/D181500