Restore handling of R_GENERIC_NONE relocations

Previously, the linker was ignoring the symbol of the R_GENERIC_NONE
relocation, so continue ignoring it. This is a little unfortunate because
it requires adding an extra condition on the fast path for relocation
handling.

I tried benchmarking this change, and I can't tell whether it has no
effect or is a regression of up to 1%. It might be possible to refactor
this code (e.g. do the lookup anyway, but avoid reporting an error), or by
changing the linker behavior, but this simple change gets the linker
working again.

Bug: http://b/147719203
Test: verify that the broken app works again
Change-Id: I7589b65705fec522d5fbadc05136dd5489833aea
This commit is contained in:
Ryan Prichard 2020-01-15 14:44:31 -08:00
parent 7909f4c667
commit 4f140695d9
1 changed files with 6 additions and 0 deletions

View File

@ -215,6 +215,12 @@ static bool process_relocation_impl(Relocator& relocator, const rel_t& reloc) {
}
};
// Skip symbol lookup for R_GENERIC_NONE relocations.
if (__predict_false(r_type == R_GENERIC_NONE)) {
trace_reloc("RELO NONE");
return true;
}
#if defined(USE_RELA)
auto get_addend_rel = [&]() -> ElfW(Addr) { return reloc.r_addend; };
auto get_addend_norel = [&]() -> ElfW(Addr) { return reloc.r_addend; };