[PATCH][GOLD] gold aarch64 erratum stubs are created but not always applied

[Peter Smith <peter dot smith at linaro dot org>]

Hello,

As a result of looking into fixing
https://sourceware.org/bugzilla/show_bug.cgi?id=20765 I checked over
the results of applying --fix-cortex-a53-843419 to a very large
program (gitit) with two stub tables and thousands of erratum fixes. I
noticed that all the erratum_stubs were being created but about 1/3 of
them were being skipped over by
fix_errata_and_relocate_erratum_stubs(). By skipped over I mean no
branch relocation or adrp -> adr transformation was applied to the
erratum address, leaving the erratum_stub unreachable, and with a
branch with a 0 immediate.

The root cause of the skipped over erratum_stubs is
Erratum_stub::invalidate_erratum_stub() that is used to set relobj_ to
NULL when an erratum_stub has been processed. Unfortunately relobj_ is
used in operator<() so altering relobj makes the results from
erratum_stubs_.lower_bound() as used in
find_erratum_stubs_for_input_section() unreliable.

I've proposed a simple fix that adds a new field that can be used in
Erratum_stub::invalidate_erratum_stub(). This preserves the order
relied upon by erratum_stubs_.lower_bound().

In theory this could hit any program with more than one relobj needing
erratum stubs, but in practice I think most small programs will get
away with it. The larger the program the greater the chance that
erratum_stubs_.lower_bound() incorrectly reporting 0 stubs found for
an input section.

This bug will be undetectable on hardware that doesn't exhibit the
erratum, but it may result on the erratum triggering on faulty
hardware even when --fix-cortex-a53-843419 is used.

Peter

Attachment: gold_use_new_field_to_track_stub_validity.diff
Description: Text document