public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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)
Date: Wed, 6 Jan 2021 08:50:43 +0100 (CET)	[thread overview]
Message-ID: <nycvar.YFH.7.76.2101060844320.17979@zhemvz.fhfr.qr> (raw)
In-Reply-To: <AM0PR0602MB34101AEAB0005EF44E68B7B4E4D00@AM0PR0602MB3410.eurprd06.prod.outlook.com>

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.

  reply	other threads:[~2021-01-06  7:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-04 20:06 Bernd Edlinger
2021-01-04 21:45 ` Jeff Law
2021-01-06  7:52   ` Bernd Edlinger
2021-01-05 12:26 ` Richard Biener
2021-01-06  7:01   ` Alexandre Oliva
2021-01-06  7:36     ` Bernd Edlinger
2021-01-06  7:50       ` Richard Biener [this message]
2021-01-06 10:07         ` Jakub Jelinek
2021-01-07  7:27           ` Richard Biener
2021-01-05 13:09 ` Alexandre Oliva
2021-01-06 11:49 ` Eric Botcazou
2021-01-06 12:26   ` Bernd Edlinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.YFH.7.76.2101060844320.17979@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=oliva@adacore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).