On 07/16/2018 03:34 PM, Jakub Jelinek wrote: > 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?
AFAIU now, the concept of location views addresses this problem, so yes. > 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. Right, but in the mean time I don't mind having an option that lets me filter out noise in guality test results. Thanks, - Tom