From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from mx2.suse.de (mx2.suse.de [195.135.220.15])
 by sourceware.org (Postfix) with ESMTPS id 7C3813857C4F
 for <gcc-patches@gcc.gnu.org>; Wed,  6 Jan 2021 07:50:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7C3813857C4F
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=rguenther@suse.de
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.221.27])
 by mx2.suse.de (Postfix) with ESMTP id 628BCADC4;
 Wed,  6 Jan 2021 07:50:43 +0000 (UTC)
Date: Wed, 6 Jan 2021 08:50:43 +0100 (CET)
From: Richard Biener <rguenther@suse.de>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
cc: Alexandre Oliva <oliva@adacore.com>, 
 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>, 
 Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH] Add line debug info for virtual thunks (PR ipa/97937)
In-Reply-To: <AM0PR0602MB34101AEAB0005EF44E68B7B4E4D00@AM0PR0602MB3410.eurprd06.prod.outlook.com>
Message-ID: <nycvar.YFH.7.76.2101060844320.17979@zhemvz.fhfr.qr>
References: <AM0PR0602MB34107607C2FC922F18F7AB34E4D20@AM0PR0602MB3410.eurprd06.prod.outlook.com>
 <nycvar.YFH.7.76.2101051322560.17979@zhemvz.fhfr.qr>
 <or35ze4kgu.fsf@lxoliva.fsfla.org> 
 <AM0PR0602MB34101AEAB0005EF44E68B7B4E4D00@AM0PR0602MB3410.eurprd06.prod.outlook.com>
User-Agent: Alpine 2.21 (LSU 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2021 07:50:45 -0000

On Wed, 6 Jan 2021, Bernd Edlinger wrote:

> On 1/6/21 8:01 AM, Alexandre Oliva wrote:
> > On Jan  5, 2021, Richard Biener <rguenther@suse.de> wrote:
> > 
> >> But isn't this a consumer issue then?  If there is no line info for
> >> a PC range then gdb shouldn't display any.
> > 
> > No, there *is* line info there, carried over from an earlier .loc
> > directive, as there isn't anything like ".noloc" to output with a
> > function that is not expected or supposed to have line number info.
> > 
> > Without that, the assembler just extends the previous .loc directive
> > onto the function.
> > 
> 
> Theoretically we could exclude the range of the no-loc function
> from the .debug_ranges, then gdb would not even step into the function.

I'd argue we're failing to emit a .endloc at the end of functions
(rather than issueing a .noloc at the start of functions with no 
locations).  I wonder if using a special file ID and switching to that
would be an effective workaround?  When gas is extended we could use
file ID zero for this (which gas currently rejects).

> However if we have at least a single line info as in the case of the thunks,
> then that would be better than nothing (what this patch does).

But the problem extends to functins which do not have any line, so what
line do you use in that case?

Richard.