Re: [PATCH+DOC] Print registers not saved in the frame as "<not saved>", instead of "<optimized out>".

[Pedro Alves <palves@redhat.com>]

On 09/18/2013 05:30 PM, Eli Zaretskii wrote:
>> Date: Wed, 18 Sep 2013 16:54:27 +0100
>> From: Pedro Alves <palves@redhat.com>
>> CC: gdb-patches@sourceware.org, Mark Kettenis <mark.kettenis@xs4all.nl>
>>
>> Eli, I've added NEWS and documentation changes to this patch.
>> Are those OK?
> 
> Almost.
> 
>> +* GDB now shows "<not saved>" when printing values of registers that
>> +  have not been saved in the frame:
>> +
>> +    (gdb) p $rax $1 = <not saved>
>> +    (gdb) info registers rax rax <not saved>
> 
> Wrong formatting of what GDB prints.

Blah.  Bad copy/paste.  Thanks.

> 
>> +In some ABIs, some registers may not be preserved, or saved, across
>> +function calls.  It may therefore not be possible for @value{GDBN} to
>> +know the value a register had before the call (in other words, in a
>                                                                      ^
> "the"

Fixed.

> 
>> +outer frame).  Values of registers that @value{GDBN} can tell were not
>> +saved in their stack frames are shown as @w{@samp{<not saved>}}.
>> +
>> +However, if debug or unwind information is missing, @value{GDBN} must
>> +deduce where registers are saved, from the machine code generated by
>> +your compiler.  If some registers are not saved, or if @value{GDBN} is
>> +unable to locate the saved registers, the selected stack frame makes
>> +no difference.
> 
> I don't understand the significance of the last paragraph.

It's preexisting actually.  I just added the "debug or unwind info" bit.
But yeah, it's confusing.  I _think_ I know what it's talking about.
I think "makes no difference" refers to GDB assuming $reg in an outer
frame is found at the same location as in the inner frame (that is,
assuming the call clobbered register hasn't been clobbered yet).

I've rewritten all this text now.  What do you think?

> Also, shouldn't we mention optimizations as (the main) reason for
> registers being unavailable?

I'm not actually sure how to say that.  Not sure you actually
always need optimization to see this in the debugger.  But maybe
we don't need to in this new version.  :-)

diff --git c/gdb/NEWS w/gdb/NEWS
index af06a21..7c10cbb 100644
--- c/gdb/NEWS
+++ w/gdb/NEWS
@@ -15,6 +15,19 @@

 * The "catch syscall" command now works on arm*-linux* targets.

+* GDB now shows "<not saved>" when printing values of registers the
+  debug info indicates have not been saved in the frame and there's
+  nowhere to retrieve them from:
+
+    (gdb) p $rax
+    $1 = <not saved>
+
+    (gdb) info registers rax
+    rax            <not saved>
+
+  Before, the former would print "<optimized out>", and the latter
+  "*value not available*".
+
 * Python scripting

   ** Frame filters and frame decorators have been added.
diff --git c/gdb/doc/gdb.texinfo w/gdb/doc/gdb.texinfo
index 60d2877..d122874 100644
--- c/gdb/doc/gdb.texinfo
+++ w/gdb/doc/gdb.texinfo
@@ -10031,10 +10031,21 @@ were exited and their saved registers restored.  In order to see the
 true contents of hardware registers, you must select the innermost
 frame (with @samp{frame 0}).

-However, @value{GDBN} must deduce where registers are saved, from the machine
-code generated by your compiler.  If some registers are not saved, or if
-@value{GDBN} is unable to locate the saved registers, the selected stack
-frame makes no difference.
+In some ABIs, some registers may not be preserved, or saved, across
+function calls.  It may therefore not be possible for @value{GDBN} to
+know the value a register had before the call (in other words, in the
+outer frame), if the register has since been clobbered by the callee.
+@value{GDBN} tries to deduce where registers are saved, from the debug
+info, unwind info, or the machine code generated by your compiler.  If
+some register is not saved, or if @value{GDBN} is unable to locate the
+saved register, @value{GDBN} will assume the register in the outer
+frame had the same location and value it has in the inner frame.  This
+is usually harmless, but note however that if you change a register in
+the outer frame, you may also be affecting the inner frame.  Values of
+registers that @value{GDBN} can definitely tell from the debug/unwind
+info were not saved in their stack frames and there's nowhere to
+retrieve the original value from anymore are shown as
+@w{@samp{<not saved>}}.

 @node Floating Point Hardware
 @section Floating Point Hardware