I have been doing some Zephyr development, using their toolchain (arm-zephyr-eabi-gcc, qemu-system-xilinx-aarch64, arm-zephyr-eabi-gdb). Though I believe the issue I am reporting here is not fork-dependent, I am open to proof of the contrary. $ ~/zephyr-sdk-0.15.1/arm-zephyr-eabi/bin/arm-zephyr-eabi-gdb --version GNU gdb (Zephyr SDK 0.15.1) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. This is ARMv7-A (Cortex-A9). The exception vector is linked at 0x00100000, and its MMU region is flat. We are not using hivecs. We use the VBAR vector base address register to point to 0x00100000, accessing it via coprocessor cp15: (gdb) disass Dump of assembler code for function z_arm_prep_c: 0x00106bd8 <+0>: ldr r3, [pc, #24] ; 0x106bf8 <z_arm_prep_c+32> 0x00106bdc <+4>: push {r4, lr} 0x00106be0 <+8>: bic r3, r3, #31 => 0x00106be4 <+12>: mcr 15, 0, r3, cr12, cr0, {0} 0x00106be8 <+16>: isb sy 0x00106bec <+20>: bl 0x108a90 <z_bss_zero> 0x00106bf0 <+24>: bl 0x10789c <z_arm_interrupt_init> 0x00106bf4 <+28>: bl 0x108b74 <z_cstart> 0x00106bf8 <+32>: andseq r0, r0, r0 End of assembler dump. (gdb) p/x $r3 $3 = 0x100000 Further down the line, we jump correctly to the exception vector, so the write to VBAR was successfull. However, attempting to read VBAR via `info register` does not display a correct value for VBAR. I believe it should read 0x100000. See below: (gdb) c Continuing. Breakpoint 5, z_mapped_start () at .../vector_table.S:22 22 ldr pc, =z_arm_svc /* svc offset 8 */ (gdb) p/x $pc $5 = 0x100008 (gdb) info register VBAR VBAR 0x0 0 Is this intended behavior? Or should I not use `info register` to read VBAR? An issue has also been opened on the Xilinx qemu side: https://github.com/Xilinx/qemu/issues/75