From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Cc: "Ulrich Weigand" <uweigand@de.ibm.com>
Subject: Re: [RFC] Fix variable lifetime related problem in gdb.base/store.exp
Date: Tue, 25 Jan 2011 15:14:00 -0000 [thread overview]
Message-ID: <20110125072228.4c8e9af4@mesquite.lan> (raw)
In-Reply-To: <201101212041.p0LKfT4c029521@d06av02.portsmouth.uk.ibm.com>
On Fri, 21 Jan 2011 21:41:29 +0100 (CET)
"Ulrich Weigand" <uweigand@de.ibm.com> wrote:
> Isn't this then simply a matter of the compiler generating incorrect
> debug information? At the PC corresponding to the call site, it is
> simply not true that register ra holds the variable l, so the debug
> info shouldn't say that. Instead, the debug info should either point
> to whatever place actually holds the variable at this point, or else
> mark variable l as "optimized out" there.
>
> There's in the end not much GDB can do if debug info is just wrong.
I agree with your analysis.
Let's assume for the moment that we change the compiler to mark `l' as
"optimized out". If we do this, we should still see failures when we
attempt to either examine or set `l'. After all, we can't look at
or change values that have been optimized out.
I can think of four not entirely unreasonable courses of action:
1) Leave the test case as is with the justification that optimizing
away variables in unoptimized code is not debugger-friendly and
therefore *should* be considered a bug.
2) Avoid the problem by changing the test to use some other variable
that's not so easy to optimize out. (This is what my patch does.)
3) Change the test case to recognize the "optimized out" condition,
causing the affected tests to be XFAILed instead.
4) Do (3), but also augment the test case to modify/examine some other
variable that won't likely be optimized out.
As I ponder these options, I'm not really liking option 2 since it
doesn't allow us to learn of a potential deficiency in the compiler.
That being the case, I withdraw my patch.
Kevin
prev parent reply other threads:[~2011-01-25 14:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 23:56 Kevin Buettner
2011-01-20 12:05 ` Doug Evans
2011-01-21 20:42 ` Kevin Buettner
2011-01-21 21:52 ` Ulrich Weigand
2011-01-25 15:14 ` Kevin Buettner [this message]
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=20110125072228.4c8e9af4@mesquite.lan \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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