[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp for powerpc64le
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.opt/solib-intra-step.exp: first-hit
step^M
28 { /* first-retry */^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
...
It's a bit easier to understand what happens if we do a full stepping session:
...
Temporary breakpoint 1, main ()
at solib-intra-step-main.c:23
23 shlib_first ();
(gdb) step
shlib_first () at solib-intra-step-lib.c:29
29 shlib_second (0); /* first-hit */
(gdb) step
28 { /* first-retry */
(gdb) step
29 shlib_second (0); /* first-hit */
(gdb) step
shlib_second (dummy=0)
at solib-intra-step-lib.c:23
23 abort (); /* second-hit */
...
and compare that to the line info:
...
CU: solib-intra-step-lib.c:
File name Line number Starting address View Stmt
solib-intra-step-lib.c 22 0x710 x
solib-intra-step-lib.c 23 0x724 x
solib-intra-step-lib.c 28 0x740 x
solib-intra-step-lib.c 29 0x74c x
solib-intra-step-lib.c 28 0x750 x
solib-intra-step-lib.c 29 0x758 x
solib-intra-step-lib.c 30 0x760 x
solib-intra-step-lib.c - 0x77c
...
So we step from line 29 to line 28, and back to line 29, which is behaviour
that matches the line table. The peculiar order is due to using optimization.
The problem is that the test-case doesn't expect this order.
Fix this by allowing this order in the test-case.
Tested on powerpc64le-linux.
PR testsuite/29792
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29792
1 file changed