From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: tromey@redhat.com
Cc: gdb-patches@sourceware.org
Subject: [commit] Fix "return" command (Re: RFC: optimized-out pieces)
Date: Mon, 14 Jun 2010 12:13:00 -0000 [thread overview]
Message-ID: <201006141213.o5ECDJgj031946@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <m3typivc5b.fsf@fleche.redhat.com> from "Tom Tromey" at Jun 04, 2010 01:19:28 PM
Tom Tromey wrote:
> Now, value_contents and friends will error if the value has been
> optimized out. This is true even if a piece of the value has been
> optimized out. This means that "naive" uses of the contents of a value
> do not need to be changed.
This causes several hundred FAILs on PowerPC because the "return"
command is now completely broken. Instead of actually implementing
the "return" action, the command now simply immediately fails with
an error message: "value has been optimized out".
The problem is that return_command calls frame_pop, which calls
frame_save_as_regcache to retrieve the unwound register values
that are to be restored. This in turn involves in the end calling
frame_register_unwind for each register, which does:
value = frame_unwind_register_value (frame, regnum);
gdb_assert (value != NULL);
*optimizedp = value_optimized_out (value);
*lvalp = VALUE_LVAL (value);
*addrp = value_address (value);
*realnump = VALUE_REGNUM (value);
if (bufferp)
memcpy (bufferp, value_contents_all (value),
TYPE_LENGTH (value_type (value)));
Now the problem is that if any of those registers cannot be unwound,
such that frame_unwind_register_value returns an optimized-out value,
the value_contents_all call will now throw an exception, which kills
the whole return_command execution.
But this is pretty common occurrence, since usually some registers
indeed cannot be unwound (e.g. because they're call-clobbered).
[ Note that this unfortunately may not show up on Intel because of
somewhat weird behaviour of the DWARF CFI layer: GCC will not
generate *any* CFI records for registers that are call-clobbered
according to the platform ABI. The default GDB handling of this
case will consider these as DWARF2_FRAME_REG_UNSPECIFIED, which
are treated as "same value as next frame". This is really not
quite correct, and leads to stale register values shown with
"info register" on any non-innermost frame. Some platforms,
*but not Intel* fix this by means of a dwarf2_frame_init_reg
routine that marks ABI call-clobbered registers instead as
DWARF2_FRAME_REG_UNDEFINED. On such platforms, the error will
show up just about every time. ]
Now it seems to me that in any case, it is not expected behaviour
for frame_register_unwind to throw an exception if the register
could not be unwound. After all, it explicitly *returns* that
fact via the optimizedp parameter to its caller! The caller
is expected to take proper actions if the value is indeed not
available. [ And frame_save_as_regcache actually does so. ]
On the other hand, it does not make sense to memcpy an
uninitialized value either. Thus, it seems the correct fix
is to simply skip the memcpy, and hence the value_contents_all
call, if the register value is "optimized out".
The patch below implements this check, and indeed fixes all the
regressions I'm seeing on powerpc(64)-linux.
Tested on powerpc(pc)-linux, committed to mainline.
Bye,
Ulrich
ChangeLog:
* frame.c (frame_register_unwind): Do not access contents
of "optimized out" unwound register value.
Index: gdb/frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.283
diff -u -p -r1.283 frame.c
--- gdb/frame.c 14 May 2010 19:27:05 -0000 1.283
+++ gdb/frame.c 13 Jun 2010 17:00:15 -0000
@@ -771,7 +771,7 @@ frame_register_unwind (struct frame_info
*addrp = value_address (value);
*realnump = VALUE_REGNUM (value);
- if (bufferp)
+ if (bufferp && !*optimizedp)
memcpy (bufferp, value_contents_all (value),
TYPE_LENGTH (value_type (value)));
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2010-06-14 12:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-04 19:19 RFC: optimized-out pieces Tom Tromey
2010-06-04 21:42 ` Tom Tromey
2010-06-07 22:35 ` Jan Kratochvil
2010-06-08 18:36 ` Tom Tromey
2010-06-08 18:42 ` Jan Kratochvil
2010-06-08 18:57 ` Tom Tromey
2010-06-09 5:50 ` Jan Kratochvil
2010-06-10 17:14 ` Tom Tromey
2010-06-11 15:34 ` Tom Tromey
2010-06-14 12:07 ` Frederic Riss
2010-06-15 15:54 ` Tom Tromey
2010-06-09 18:44 ` Jan Kratochvil
2010-06-14 12:13 ` Ulrich Weigand [this message]
2010-06-15 15:58 ` [commit] Fix "return" command (Re: RFC: optimized-out pieces) Tom Tromey
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=201006141213.o5ECDJgj031946@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.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