From: Richard Biener <rguenther@suse.de>
To: Eric Botcazou <botcazou@adacore.com>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
gcc-patches@gcc.gnu.org, Arnaud Charlet <charlet@adacore.com>
Subject: Re: [PATCH 2/2] Ada: Remove debug line number for DECL_IGNORED_P functions
Date: Tue, 10 Aug 2021 09:23:45 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.2108100921290.11781@zhemvz.fhfr.qr> (raw)
In-Reply-To: <1886121.usQuhbGJ8B@arcturus>
On Mon, 9 Aug 2021, Eric Botcazou wrote:
> > But it is okay that we can set a breakpoint on defs__struct1IP,
> > in the test case of PR 101598.
> > And the debugger shall only show assembler here.
> > Right?
>
> The defs__struct1IP procedure should be totally transparent for the user, so
> setting a breakpoint in it is not supposed to come into play.
>
> > Do you have an example where this location information is used in the
> > compiler itself for debugging?
>
> That's useful when you compile the code with -gnatD, i.e when you debug the
> intermediate code generated by the front-end.
>
> > I assume You would agree that having the location for Test2 is better
> > than no debug info at all?
>
> But we want no debug info at all for these IP functions.
>
> > What do you think?
>
> I guess I still don't understand why DECL_IGNORED_P was changed.
ISTR it was changed because at least with location info generated
by gas there's no way to have "no location" for a portion of code.
Instead the assigned location will be that of the previous .loc
directive which results in random and confusing results for the
pc range of the DECL_INGORED_P function.
I guess we should really revisit the decision to rely on gas
to produce line info. What's the advantage of doing so (apart
from "nice" annotated assembly)?
Richard.
next prev parent reply other threads:[~2021-08-10 7:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-26 16:45 Bernd Edlinger
2021-08-02 13:07 ` Eric Botcazou
2021-08-02 17:18 ` Bernd Edlinger
2021-08-04 14:33 ` Eric Botcazou
2021-08-04 17:59 ` Bernd Edlinger
2021-08-09 14:37 ` Eric Botcazou
2021-08-10 7:23 ` Richard Biener [this message]
2021-08-10 15:46 ` Eric Botcazou
2021-08-10 9:43 ` Bernd Edlinger
2021-08-10 20:56 ` Eric Botcazou
2021-08-11 5:27 ` 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.2108100921290.11781@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=bernd.edlinger@hotmail.de \
--cc=botcazou@adacore.com \
--cc=charlet@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
/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).