From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121094 invoked by alias); 30 Apr 2019 05:49:56 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 121085 invoked by uid 89); 30 Apr 2019 05:49:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=hay, HTo:U*amodra, pero, fighter X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Apr 2019 05:49:54 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4F47A3084249; Tue, 30 Apr 2019 05:49:53 +0000 (UTC) Received: from free.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CC1BF18000; Tue, 30 Apr 2019 05:49:52 +0000 (UTC) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTP id x3U5ncEQ024309; Tue, 30 Apr 2019 02:49:40 -0300 From: Alexandre Oliva To: Alan Modra Cc: binutils@sourceware.org Subject: Re: [PR24444] speed up locview resolution wiht relaxable frags References: <20190414132247.GO14424@bubble.grove.modra.org> <20190424231820.GE9648@bubble.grove.modra.org> Date: Tue, 30 Apr 2019 05:49:00 -0000 In-Reply-To: <20190424231820.GE9648@bubble.grove.modra.org> (Alan Modra's message of "Thu, 25 Apr 2019 08:48:20 +0930") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-04/txt/msg00261.txt.bz2 On Apr 24, 2019, Alan Modra 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 =3D (!(.L3 > .L2)) * (.Lv2 + 1) .Lv5 =3D (!(.L5 > .L4)) * (.LV4 + 1) while we should really compute: .Lv3 =3D (.L3 =3D=3D .L5) * (.LV5 + 1) .LV5 =3D (.L5 =3D=3D .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? --=20 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=C3=A1s-GNUChe