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

Pedro Alves
2013-09-19T16:58:41Z

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