Quuxplusone
commented
5 years ago (In reply to Jeremy Morse from comment #0)
> Gdbs interpretation on stepping into foo:
>
> (gdb) frame
> #0 foo (eyelids=...) at test.cpp:8
> 8 {
> (gdb) print eyelids
> $1 = {a = 1, b = 4195504}
By stepping, do you mean stepping to the first instruction in the function, or
a normal line number step?
With r350008, when doing a line number step into the function, meaning that we
land after the prologue end, eyelids is printed with the right values for me:
(gdb) b *foo
Breakpoint 1 at 0x4004c0: file pr40188.c, line 8.
(gdb) b foo
Breakpoint 2 at 0x4004c7: file pr40188.c, line 9.
(gdb) run
Starting program: /home/edasten/upstream/master/a.out
Breakpoint 1, foo (eyelids=...) at pr40188.c:8
8 {
(gdb) print eyelids
$1 = {a = 1, b = 4195536}
(gdb) c
Continuing.
Breakpoint 2, foo (eyelids=...) at pr40188.c:9
9 return eyelids.a + eyelids.b;
(gdb) print eyelids
$2 = {a = 1, b = 2}
and eyelids.b is printed incorrect at first instruction in the function.
If the file is instead compiled with -O0, then a single location description is
emitted, which says that the argument is located on the stack, meaning that we
will print the parameter using garbage stack data at the first instruction of
the function:
(gdb) b *foo
Breakpoint 1 at 0x4004c0: file pr40188.c, line 8.
(gdb) b foo
Breakpoint 2 at 0x4004c8: file pr40188.c, line 9.
(gdb) run
Starting program: /home/edasten/upstream/master/a.out
Breakpoint 1, foo (eyelids=...) at pr40188.c:8
8 {
(gdb) print eyelids
$1 = {a = 0, b = 0}
(gdb) disas
Dump of assembler code for function foo:
=> 0x00000000004004c0 <+0>: push %rbp
0x00000000004004c1 <+1>: mov %rsp,%rbp
0x00000000004004c4 <+4>: mov %rdi,-0x8(%rbp)
0x00000000004004c8 <+8>: mov -0x8(%rbp),%eax
0x00000000004004cb <+11>: add -0x4(%rbp),%eax
0x00000000004004ce <+14>: pop %rbp
0x00000000004004cf <+15>: retq
End of assembler dump.
It seems to be me that we should not expect to be able to print parameters with
the correct values (or as unavailable rather than with incorrect values) inside
the prologue for optimized code, if we can't do that in non-optimized cases? Or
am I overlooking something here?
remove.p(1559 bytes, text/plain)build.log(106712 bytes, text/x-log)