From: Joel Brobecker <brobecker@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] Fix "break foo" when `foo's prologue ends before line table
Date: Mon, 11 May 2009 21:28:00 -0000 [thread overview]
Message-ID: <20090511212744.GB7584@adacore.com> (raw)
In-Reply-To: <83tz3rxt4p.fsf@gnu.org>
> Are such rearrangements permitted? I mean, are we talking about a
> real-life situation here?
I think they are permitted, especially if the statements are not
function calls. For instance, the compiler can certainly reverse
the following two statements:
a = 1;
b = 2;
I am not versed in the art of optimizing, but why not. I don't think
anything is forbidden as long as the program works as expected.
That being said, the example was just an extreme on meant to show
what it means to chose the line with the smaller number, and why
I prefer to select the first line in your case.
But, like you, I'm not too concerned about which line to select.
In practice, it's not going to happen much. Even for you, I'm betting
that it's only happen when breaking on "main", because the compiler
should generate that stack re-alignment code only in the main, and
on functions that have special attributes meaning that it might be
called from some code whose stack is less aligned.
> > In other words, when I break on
> > a function, I expect that by the time I reach that function breakpoint,
> > none of the real code has been executed yet - I want to debug the
> > function :-).
>
> This could be impossible anyway, if the compiler moves some of the
> body into the prologue, right?
I can't remember what we do in that case. I'd have to look at
the code again.
> Well, granted, I've seen that comment. But (a) are we sure all of our
> comments are necessarily accurate to rely on them?, and (b) it
> continues to say
>
> If there is more than
> one entry for a given pc, then I'm not sure what should happen (and
> I not sure whether we currently handle it the best way).
>
> Not very reassuring...
At least for the part that lines are sorted by ascending PC order,
I'm pretty sure. If we break that assumption, we should fix it,
because I think we rely on it in several places.
--
Joel
next prev parent reply other threads:[~2009-05-11 21:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-09 14:26 Eli Zaretskii
2009-05-11 12:56 ` Joel Brobecker
2009-05-11 18:21 ` Eli Zaretskii
2009-05-11 19:27 ` Joel Brobecker
2009-05-11 20:49 ` Eli Zaretskii
2009-05-11 21:20 ` Daniel Jacobowitz
2009-05-12 3:13 ` Eli Zaretskii
2009-05-11 21:28 ` Joel Brobecker [this message]
2009-05-16 11:18 ` Eli Zaretskii
2009-05-20 23:07 ` Joel Brobecker
2009-05-23 10:20 ` Eli Zaretskii
2009-05-25 7:26 ` Joel Brobecker
2009-05-11 19:42 ` Daniel Jacobowitz
2009-05-11 20:40 ` Eli Zaretskii
2009-05-11 21:19 ` Joel Brobecker
2009-05-12 3:09 ` Eli Zaretskii
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=20090511212744.GB7584@adacore.com \
--to=brobecker@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.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