[PR24444] speed up locview resolution wiht relaxable frags

[Alexandre Oliva]

On Apr 24, 2019, Alan Modra <amodra@gmail.com> wrote:

> I pushed the following for you.

Thanks for taking care of this while I convalesced.


I'm afraid we may still have a problem I hadn't realized before.

Consider two text subsections, say 0 and 1.

We switch from 0 to 1 and output a loc with a view.

Later we switch back, and also output a loc with a view.

Once addresses are resolved, one of these will have necessarily gone
from a higher offset to a lower offset within the text section.  In rare
cases, the subsection boundary may actually have locviews in both
subsections, at the same address.

O_gt would give us an answer that does not match the expectation that we
should reset view when PC changes.

However, it may be worse than that.  Loc view expressions are chained
back to the previous loc view present in the asm input, even if it's in
a different section.

This means O_gt on loc addresses will give us the wrong result when we
switch between subsections from higher to lower address, and it will
also likely give us the wrong result at the boundary.

Consider:

.text 0
.loc 1 1 view -0
nop
.L2: .loc 1 2 view .LV2
.text 1
.L3: .loc 1 3 view .LV3
nop
.L4: .loc 1 4 view .LV4
.text 0
.L5: .loc 1 5 view .LV5

We'll compute:

.LV3 = (!(.L3 > .L2)) * (.Lv2 + 1)
.Lv5 = (!(.L5 > .L4)) * (.LV4 + 1)

while we should really compute:

.Lv3 = (.L3 == .L5) * (.LV5 + 1)
.LV5 = (.L5 == .L2) * (.LV2 + 1)

because the reordered text section, based on which we output the line
number program, is:

.text
.loc 1 1 view -0
nop
.L2: .loc 1 2 view .LV2 # 0
.L5: .loc 1 5 view .LV5 # 1
# --- transition from .text 0 to .text 1
.L3: .loc 1 3 view .LV3 # 2
nop
.L4: .loc 1 4 view .LV4 # 0

AFAICT fixing this will require introducing artificial undefined symbols
to be used as previous view label and previous view number for each
subsection, and then, when ordering subsections and sections, defining
the initial previous symbols of each subsection as equal to the final
previous symbols of the previous subsection in the same section.

Maybe with this arrangement we can keep on using O_gt, though reducing
the depth of the loc view expressions feels appealing in the context of
this PR.

Any better ideas?

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free!         FSF Latin America board member
GNU Toolchain Engineer                Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe