This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[commit] Fix "return" command (Re: RFC: optimized-out pieces)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]