public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Alexandre Oliva <oliva@adacore.com>
Subject: Re: [PATCH] Add line debug info for virtual thunks (PR ipa/97937)
Date: Wed, 6 Jan 2021 11:07:55 +0100	[thread overview]
Message-ID: <20210106100755.GB725145@tucnak> (raw)
In-Reply-To: <nycvar.YFH.7.76.2101060844320.17979@zhemvz.fhfr.qr>

On Wed, Jan 06, 2021 at 08:50:43AM +0100, Richard Biener wrote:
> > 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).

If we had .endloc, emitting it at the end of functions would be
theoretically more correct, but I'd be afraid it would unnecessarily grow
the .debug_line size, because nobody should care about line information in
padding bytes between functions and the .endloc would add there a change
even when it would affect just one byte of padding (probably even when it
wouldn't affect anything, depending on how it is implemented).

	Jakub


  reply	other threads:[~2021-01-06 10:08 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
2021-01-06 10:07         ` Jakub Jelinek [this message]
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=20210106100755.GB725145@tucnak \
    --to=jakub@redhat.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=oliva@adacore.com \
    --cc=rguenther@suse.de \
    /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).