diff options
author | Tom de Vries <tdevries@suse.de> | 2025-01-22 10:46:08 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2025-01-22 10:46:08 +0100 |
commit | 4cbf39144c78ec78a6924466993b6788ae8d1511 (patch) | |
tree | fe8c6ad51905a66333ffbe5e1d17a55338fdf237 /sim/bpf | |
parent | c80eb5cbe7d32bcd9fbdb89f34b5882e64408173 (diff) | |
download | gdb-master.zip gdb-master.tar.gz gdb-master.tar.bz2 |
On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and
test-case gdb.base/branch-to-self.exp I run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
0x0040058c 38 for (;;); /* loop-line */^M
(gdb) FAIL: $exp: single-step: si
...
In contrast, on the same machine but with debian testing and gcc 14.2.0 we have:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: stepi
...
The difference is in the instruction(s) generated for the loop.
In the passing case, we have:
...
588: eafffffe b 588 <main+0x24>
...
and in the failing case:
...
588: e320f000 nop {0}
58c: eafffffd b 588 <main+0x24>
...
The purpose of this part of the test-case is to:
- generate a branch instruction that jumps to itself, and
- set a breakpoint on it, and check that stepi-ing from that breakpoint
triggers the breakpoint again.
As we can see, in the failing case we failed to generate a branch instruction
that jumps to itself, and consequently we cannot expect to hit the breakpoint
again after issuing a single si.
Fix this by issuing stepi until we hit the breakpoint.
Tested on arm-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Diffstat (limited to 'sim/bpf')
0 files changed, 0 insertions, 0 deletions