[Bug gdb/31070] Abnormal Jump in Execution for builtin function using 'stepi' Command in GDB

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31070

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
I can reproduce this:
...
Temporary breakpoint 1, main () at small.c:10
10        __builtin_prefetch (glob_int_arr, 0, 0);
(gdb) si
0x0000000000401044 in simple_global () at small.c:11
11        __builtin_prefetch (glob_ptr_int, 0, 0);
(gdb) si
0x000000000040104b in main () at small.c:19
19        exit (0);
(gdb) si
0x000000000040104d in simple_global () at small.c:10
10        __builtin_prefetch (glob_int_arr, 0, 0);
(gdb) si
11        __builtin_prefetch (glob_ptr_int, 0, 0);
...

When decoding the line numbers I see:
...
small.c                                       11            0x401044        
small.c                                       19            0x40104b        
small.c                                       10            0x40104d        
small.c                                       11            0x401054           
   ...
which perfectly matches the progression we see.

So gdb doesn't do anything wrong, it accurately show the line info as generated
by gcc.

So why does the insn at 0x40104b have line number 19?

The disassembly is:
...
0000000000401040 <main>:
  401040:       48 83 ec 08             sub    $0x8,%rsp
  401044:       48 8b 05 cd 2f 00 00    mov    0x2fcd(%rip),%rax        #
404018 <glob_ptr_int>
  40104b:       31 ff                   xor    %edi,%edi
  40104d:       0f 18 05 ec 2f 00 00    prefetchnta 0x2fec(%rip)        #
404040 <glob_int_arr>
  401054:       0f 18 00                prefetchnta (%rax)
  401057:       e8 d4 ff ff ff          call   401030 <exit@plt>
  40105c:       0f 1f 40 00             nopl   0x0(%rax)
...
and the call to exit is represented by these two insns:
...
  40104b:       31 ff                   xor    %edi,%edi
  401057:       e8 d4 ff ff ff          call   401030 <exit@plt>
...

Optimization separated the two insns and that causes the "jumping" through the
lines.

AFAICT, this falls in the range of expected behaviour when debugging optimized
code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.