On Mon, Jul 16, 2018 at 03:29:10PM +0200, Tom de Vries wrote:
> this is an idea that I'm currently playing around with: adding nops in
> an optimized application with debug info can improve the debug info.
>
> Consider f.i. this gdb session in foo of pr54200-2.c (using -Os):
> ...
> (gdb) n
> 26 return a; /* { dg-final { gdb-test . "(int)a" "6" } } */
> (gdb) p a
> 'a' has unknown type; cast it to its declared type
> (gdb) n
> main () at pr54200-2.c:34
> 34 return 0;
> ...
>
> The problem is that the scope in which a is declared ends at .LBE7, and the
> statement .loc for line 26 ends up attached to the ret insn:
> ...
> .loc 1 24 11
> addl %edx, %eax
> .LVL1:
> # DEBUG a => ax
> .loc 1 26 7 is_stmt 1
> .LBE7:
> .loc 1 28 1 is_stmt 0
> ret
> .cfi_endproc
> ...
>
> This patch fixes the problem (for Og and Os, the 'DEBUG a => ax' is missing
> for O1 and higher) by adding a nop before the ret insn:
> ...
> .loc 1 24 11
> addl %edx, %eax
> .LVL1:
> # DEBUG a => ax
> .loc 1 26 7 is_stmt 1
> + nop
> .LBE7:
> .loc 1 28 1 is_stmt 0
> ret
> .cfi_endproc
> ...
>
> and instead we have:
> ...
> (gdb) n
> 26 return a; /* { dg-final { gdb-test . "(int)a" "6" } } */
> (gdb) p a
> $1 = 6
> (gdb) n
> main () at pr54200-2.c:34
> 34 return 0;
> ...
>
> Any comments?
So is this essentially a workaround for GDB not supporting the statement
frontiers? Isn't the right fix just to add that support instead and then
users can choose how exactly they want to step through the function in the
debugger.
Jakub
