syscall: 0.358
instruction: 0.340
runtime: 0.302



regression: 8.0.0 segfaults on coverage counter increment
Description of problem:
With qemu 8.0.0, my test program segfaults while incrementing a gcov counter:

```
Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 ()
(gdb) x/2i $pc
=> 0x4bc9a8 <__CortexA53843419_464004>:	str	x8, [x9, #2512]
   0x4bc9ac <__CortexA53843419_464004+4>:	b	0x464008 <mock_hyp_params_Destroy+24>
(gdb) p $x8
$10 = 1
(gdb) p $x9
$11 = 5234688
(gdb) x/x $x9+2512
0x4fe9d0 <__llvm_gcov_ctr.5>:	0x00000000
(gdb) stepi

Program received signal SIGSEGV, Segmentation fault.
0x00000000004bc9a8 in __CortexA53843419_464004 ()
(gdb) x/x $x9+2512
0x4fe9d0 <__llvm_gcov_ctr.5>:	0x00000000
(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep  4fe9d0
00000000004fe9d0 l     O .bss	0000000000000008 __llvm_gcov_ctr.5
(gdb) shell qemu-aarch64 --version
qemu-aarch64 version 8.0.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
(gdb) 
```

With qemu 6.2.0, it doesn't segfault (at least not at this point, you
may ignore the segfault at the end due to a bug in the test program).
```
$ /usr/bin/qemu-aarch64  --version
qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

$ /usr/bin/qemu-aarch64  ./build/gcov/out/test_hyp-props.out
test_hyp-props.c:13:test__setup_str_prop:PASS
test_hyp-props.c:14:test__log_print_handler:PASS
test_hyp-props.c:15:test__setup_log_print_prop:PASS
test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS
test_hyp-props.c:17:test__vm_info_alloc:PASS
test_hyp-props.c:18:test__memory_status_get:PASS
test_hyp-props.c:19:test__memory_status_get_fail:PASS
Segmentation fault (core dumped)
```
Steps to reproduce:
1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage.
2. Run it with qemu-aarch64 8.0.0
3. Hopefully, it will segfault early for no good reason.