[gdb/tdep] Handle ldaex and stlex in {thumb,arm}_deal_with_atomic_sequence_raw

The Linaro CI reported a regression [1] in test-case
gdb.base/step-over-syscall.exp due to commit 674d4856730 ("[gdb/testsuite] Fix
gdb.base/step-over-syscall.exp with glibc 2.41").

Investigation shows that it's a progression in the sense that the test-case
fails at a later point than before.

The cause for the test-case failure is that an atomic sequence
ldaex/adds/strex is not skipped over when instruction stepping, leading to a
hang (in the sense of not being able to instruction-step out of the loop
containing the atomic sequence).

The arm target does have support for recognizing atomic sequences, but it
fails because it doesn't recognize the ldaex insn.

Fix this by:
- adding a new function ldaex_p which recognizes ldaex instructions, based
  on information found in opcodes/arm-dis.c, and
- using ldaex_p in thumb_deal_with_atomic_sequence_raw.

I was not able to reproduce the failure in its original setting, but I
was able to do so using a test.c:
...
static void exit (int status) {
  while (1)
    ;
}
void _start (void) {
  int a = 0;
  __atomic_fetch_add (&a, 1, __ATOMIC_ACQUIRE);
  exit (0);
}
...
compiled like this:
...
$ gcc test.c -march=armv8-a -mfloat-abi=soft -nostdlib -static
...
giving this atomic sequence of 32-bit Thumb-2 instructions:
...
   100ce:       e8d3 1fef       ldaex   r1, [r3]
   100d2:       f101 0101       add.w   r1, r1, #1
   100d6:       e843 1200       strex   r2, r1, [r3]
...

Without the fix, after 100 stepi's we're still in _start (and likewise with
10.000 stepi's):
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
  ...
0x000100dc in _start ()
1: x/i $pc
=> 0x100dc <_start+26>:	bne.n	0x100ce <_start+12>
...
but with the fix we've managed to progress to exit:
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
  ...
0x000100c0 in exit ()
1: x/i $pc
=> 0x100c0 <exit+8>:	b.n	0x100c0 <exit+8>
...

Having addressed the "-mthumb" case, do we need a similar fix for "-marm"?

Adding "-marm" in the compilation line mentioned above gives the following
atomic sequence:
...
   100e4:       e1931e9f        ldaex   r1, [r3]
   100e8:       e2811001        add     r1, r1, #1
   100ec:       e1832f91        strex   r2, r1, [r3]
...
and gdb already recognizes it as such because of this statement:
...
  if ((insn & 0xff9000f0) != 0xe1900090)
    return {};
...

The trouble with this statement is that it requires knowledge of arm
instruction encoding to understand which cases it does and doesn't cover.

Note that the corresponding comment only mentions ldrex:
...
  /* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */
...
but evidently at least some forms of ldaex are also detected.

So, also use ldaex_p in arm_deal_with_atomic_sequence_raw.  This may or may
not be redundant, but at least ldaex_p is explicit and precise about what it
supports.

Likewise for stlex (generated when using __ATOMIC_RELEASE instead of
__ATOMIC_ACQUIRE in the example above).

Tested in arm-linux chroot on aarch64-linux.

Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Co-Authored-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>

PR tdep/32796
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32796

[1] https://linaro.atlassian.net/browse/GNU-1541

0 files changed, 0 insertions, 0 deletions