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

[Pedro Alves <palves@redhat.com>]

On 09/19/2013 08:53 AM, Eli Zaretskii wrote:
>> Date: Wed, 18 Sep 2013 22:47:24 +0200 (CEST)
>> From: Mark Kettenis <mark.kettenis@xs4all.nl>
>> CC: palves@redhat.com, aburgess@broadcom.com, gdb-patches@sourceware.org,
>>         mark.kettenis@xs4all.nl
>>
>>> Date: Wed, 18 Sep 2013 19:30:07 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>>
>>> Also, shouldn't we mention optimizations as (the main) reason for
>>> registers being unavailable?
>>
>> I don't consider optimisations as an important cause of registers not
>> being saved.
> 
> The question is: does it happen in practice?  If it does, I think we
> should mention that, because it's important to let the users know that
> recompiling without optimizations might remove this nuisance.

I think it's really independent of optimization.

Jan's comments at <https://sourceware.org/ml/gdb-patches/2012-08/msg00787.html>
help understand this.   Current/recent enough GCC doesn't mark variables/arguments
as being in call-clobbered registers in the ranges corresponding to function calls,
while older GCCs did.  Newer GCCs will just not say where the variable is, so GDB
will end up realizing the variable is optimized out.  In fact, if I build
an -O2 version of GDB, and do

 $ readelf --debug-dump=frames ./gdb | grep DW_CFA_undefined

nothing comes out.

Now, GDB itself could just assume that call-clobbered registers
are always <not saved> in frames other than the innermost, but
that'll be not very user friendly, I think.

Perhaps... we should completely toss out this patch, and go
the other way around.  When printing registers of an outer
frame, ignore DW_CFA_undefined, and read the registers
from the inner frame anyway...  IOW, define the values of
call-clobbered registers in outer frames as "the values the
registers would have if the inner frame returned _now_".
Mark, what do you think?
(I didn't try implementing that, but I think that'll just
mean ignoring the optimized_out flag when dumping registers
(but not when printing variables marked as living in "optimized
out" registers).

I wondered what would the "return" command do if forcing
a return to a function where we current show registers
as "<optimized out>/<not saved>", to see if that
would through a "value optimized out" error or some such.
It actually doesn't:

Breakpoint 2, stop_frame () at dw2-reg-undefined.c:22
22      in dw2-reg-undefined.c
(gdb) info registers
rax            0x0      0
rbx            0x0      0
rcx            0x400552 4195666
rdx            0x7fffffffdb18   140737488345880
rsi            0x7fffffffdb08   140737488345864
rdi            0x1      1
rbp            0x7fffffffda00   0x7fffffffda00
rsp            0x7fffffffda00   0x7fffffffda00
r8             0x323d7b1f40     215779843904
r9             0x323d00f310     215771837200
r10            0x7fffffffd880   140737488345216
r11            0x323d421640     215776106048
r12            0x400430 4195376
r13            0x7fffffffdb00   140737488345856
r14            0x0      0
r15            0x0      0
rip            0x400540 0x400540 <stop_frame+4>
eflags         0x246    [ PF ZF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) up
#1  0x0000000000400550 in first_frame () at dw2-reg-undefined.c:27
27      in dw2-reg-undefined.c
(gdb) info registers
rax            <optimized out>
rbx            <optimized out>
rcx            <optimized out>
rdx            <optimized out>
rsi            <optimized out>
rdi            <optimized out>
rbp            0x7fffffffda10   0x7fffffffda10
rsp            <optimized out>
r8             0x323d7b1f40     215779843904
r9             0x323d00f310     215771837200
r10            0x7fffffffd880   140737488345216
r11            0x323d421640     215776106048
r12            0x400430 4195376
r13            0x7fffffffdb00   140737488345856
r14            0x0      0
r15            0x0      0
rip            0x400550 0x400550 <first_frame+14>
eflags         0x246    [ PF ZF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) down
#0  stop_frame () at dw2-reg-undefined.c:22
22      in dw2-reg-undefined.c
(gdb) return
Make stop_frame return now? (y or n) y
#0  first_frame () at dw2-reg-undefined.c:28
28      in dw2-reg-undefined.c
(gdb) info registers
rax            0x0      0
rbx            0x0      0
rcx            0x400552 4195666
rdx            0x7fffffffdb18   140737488345880
rsi            0x7fffffffdb08   140737488345864
rdi            0x1      1
rbp            0x7fffffffda10   0x7fffffffda10
rsp            0x7fffffffda00   0x7fffffffda00
r8             0x323d7b1f40     215779843904
r9             0x323d00f310     215771837200
r10            0x7fffffffd880   140737488345216
r11            0x323d421640     215776106048
r12            0x400430 4195376
r13            0x7fffffffdb00   140737488345856
r14            0x0      0
r15            0x0      0
rip            0x400550 0x400550 <first_frame+14>
eflags         0x246    [ PF ZF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb)

In case that isn't clear, GDB did fetch the values of
call-clobbered registers from the inner frame.  I didn't
check where/how that happens.

-- 
Pedro Alves