Bug 488169

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY:

There is a VEX instrumentation error for arm-64 when instrumenting some return sequence instructions.  This error results an infinite loop of instrumentation because VEX is not correctly getting the return address on a ret instruction in these cases (details about one function with this error in it, including its full disassembled pre-VEX instrumented version of the code is below).

The bug is present in the lackey tool when run with --trace-superblocks=yes and/or --trace-mem=yes.  

NOTE: your lackey test code does not test all its command line options.  Otherwise, I'm  sure you would see this too.

Please fix this error with VEX on arm. We are using superblock-level instrumentation in our valgrind tool that works for x86 architectures, and we really would like to support ARM too, but this VEX error is preventing us from doing so.


STEPS TO REPRODUCE
1.   gcc -g  prog.c
2.  valgrind --tool=lackey  --trace-superblocks=yes ./a.out

 The observed result  occurs for every C program we have tried, here is an example super-trivial one that triggers it:
  % cat prog.c
  int main(int argc, char *argv) {
    int x;
    x = 1;
    return 0;
  }

OBSERVED RESULT

The code gets into an infinite loop of tracing between two superblocks, each of which jumps to the other forever (but should not.   Here is some example output from running it (more details below of what instructions these correspond to and how we figured this out, which may help you fix this VEX bug):  

  ...
  SB 04954ed8  
  SB 04954ecc
  SB 04954ed8
  SB 04954ecc
  SB 04954ed8
  SB 04954ecc
  SB 04954ed8
  SB 04954ecc
  SB 04954ed8
  SB 04954ecc
  SB 04954ed8
  ...
  repeats forever

EXPECTED RESULT

We would expect that when we run lackey with --trace-superblocks=yes on this  a.out , we would see a sequence of its SB's printed out until it the program terminates followe by lackey's regular summary  output at the end (i.e., we would expect there to be no infinite loop of SB's printed out, because this a.out does not have an infinite loop).  

SOFTWARE/OS VERSIONS

This bug is present in valgrind version 3.23.0.  We have also found it in every previous version of valgrind we tested, including 3.22.0, 3.21.0, 3.19.0, and 3.16.1.   It is present in versions we build from source as well as the default valgrind version that is installed with the debian version installed.  We have found it on both ARM-64 boards we have.

Specifically, we can replicate it on these two ARM-64 systems:

(1) linux: Linux 5.10.123-meson64 #22.05.3 SMP PREEMPT Wed Jun 22 07:23:04 UTC 2022 aarch64 GNU/Linux
    gcc (Debian 10.2.1-6) 10.2.1 2021011
    valgrind version valgrind-3.16.1   (version with debian)
    and valgrind version valgrind-3.23.0  (built from source)

(2) linux: Linux 5.15.69-rockchip64 #22.08.2 SMP PREEMPT Wed Sep 21 19:28:26 UTC 2022 aarch64 GNU/Linux
    gcc (Debian 10.2.1-6) 10.2.1 2021011
    valgrind version valgrind-3.16.1   (version with debian)
    and valgrind version valgrind-3.23.0  (built from source)


ADDITIONAL INFORMATION

Here is some information to help you fix this problem.

We found where the infinite loop is occuring (or at least one example code sequence for which it happens, and the corrosponding to the specific case above).

The infinite loop occurs in VEX's instrumentation the __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so) function called as part of _start before main is called.  Again, this occurs when instrumenting at the superblock level triggered by running lackey with --trace-superblocks=yes, and also at the memory access level triggered by running lackey with --trace-mem=yes).

This is a dump from gdb of a the originial executable (not of your VEX instrumented binary, but of the code sequence you are instrumenting in VEX).  

The infinite loop happens when ret instruction is executed (at <+48>).  The VEX instrumented code incorrectly executes n the b.ne (at <+36>) as the retun address instruction (which it incorrect), which then branches to the ret instruction (at <+48>, which uses instruction at <+36> as the return address, which ... and so on forever:

  (gdb) disass
  Dump of assembler code for function __aarch64_cas4_acq:
  => 0x0000fffff7f65eb0 <+0>:	bti	c
    0x0000fffff7f65eb4 <+4>:	adrp	x16, 0xfffff7fcb000 <resbuf.0+8>
    0x0000fffff7f65eb8 <+8>:	ldrb	w16, [x16, #4032]
    0x0000fffff7f65ebc <+12>:	cbz	w16, 0xfffff7f65ec8 <__aarch64_cas4_acq+24>
    0x0000fffff7f65ec0 <+16>:	casa	w0, w1, [x2]
    0x0000fffff7f65ec4 <+20>:	ret
    0x0000fffff7f65ec8 <+24>:	mov	w16, w0
    0x0000fffff7f65ecc <+28>:	ldaxr	w0, [x2]
    0x0000fffff7f65ed0 <+32>:	cmp	w0, w16
    0x0000fffff7f65ed4 <+36>:	b.ne	0xfffff7f65ee0 <__aarch64_cas4_acq+48>  // b.any
    0x0000fffff7f65ed8 <+40>:	stxr	w17, w1, [x2]
    0x0000fffff7f65edc <+44>:	cbnz	w17, 0xfffff7f65ecc <__aarch64_cas4_acq+28>
    0x0000fffff7f65ee0 <+48>:	ret

Here is a stack trace of where this function is called (part of the _start sequence, before main):

  (gdb) bt
  #0  0x0000fffff7f65eb0 in __aarch64_cas4_acq () from /lib/aarch64-linux-gnu/libc.so.6
  #1  0x0000fffff7e8db70 in __internal_atexit (func=0xfffff7fdab20 <_dl_fini>, arg=arg@entry=0x0,
      d=d@entry=0x0, listp=listp@entry=0xfffff7fc76b8 <__exit_funcs>) at cxa_atexit.c:43
  #2  0x0000fffff7e8dc4c in __GI___cxa_atexit (func=<optimized out>, arg=arg@entry=0x0, d=d@entry=0x0)
      at cxa_atexit.c:70
  #3  0x0000fffff7e77d90 in __libc_start_main (main=0xaaaaaaaa0724 <main>, argc=1,
      argv=0xfffffffff128, init=0xaaaaaaaa0750 <__libc_csu_init>, fini=<optimized out>,
      rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:238
  #4  0x0000aaaaaaaa0644 in _start ()


Here is some output from our modification to trace_superblock function in lackey (valgrind version 3.23.0) where we added a call to (VG_(pp_addrinfo)):

  ...
  SB 04954ecc
  ==116621==  Address 0x4954ed8 is in the Text segment of /usr/lib/aarch64-linux-gnu/libc-2.31.so
  ==116621==    at 0x4954ED8: __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so)
  SB 04954ed8
  ==116621==  Address 0x4954ecc is in the Text segment of /usr/lib/aarch64-linux-gnu/libc-2.31.so
  ==116621==    at 0x4954ECC: __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so)
  SB 04954ecc
  ==116621==  Address 0x4954ed8 is in the Text segment of /usr/lib/aarch64-linux-gnu/libc-2.31.so
  ==116621==    at 0x4954ED8: __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so)
  SB 04954ed8
  ==116621==  Address 0x4954ecc is in the Text segment of /usr/lib/aarch64-linux-gnu/libc-2.31.so
  ==116621==    at 0x4954ECC: __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so)
  SB 04954ecc
  ==116621==  Address 0x4954ed8 is in the Text segment of /usr/lib/aarch64-linux-gnu/libc-2.31.so
  ==116621==    at 0x4954ED8: __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so)
  SB 04954ed8
  ==116621==  Address 0x4954ecc is in the Text segment of /usr/lib/aarch64-linux-gnu/libc-2.31.so
  ==116621==    at 0x4954ECC: __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so)
  SB 04954ecc
  ==116621==  Address 0x4954ed8 is in the Text segment of /usr/lib/aarch64-linux-gnu/libc-2.31.so
  ==116621==    at 0x4954ED8: __aarch64_cas4_acq (in /usr/lib/aarch64-linux-gnu/libc-2.31.so)
  SB 04954ed8
  ...
  repeats forever