gdb: print AArch64 advanced SIMD vector registers (is it possible?)

Question

I am trying to debug inside my assembly code to check what values are in advanced SIMD vector registers. To this end, I run gdb and set a breakpoint inside my instructions, run layout asm and step through my instructions using si. However, when I reached to my desired instruction, p v16 for example, didn't print the value inside this register and it gave me an error like as the following:

       │0x4009d0 <Montmul512+80>        umull2 v16.2d, v15.4s, v7.s[3]                                                                         │
      >│0x4009d4 <Montmul512+84>        umull2 v17.2d, v13.4s, v7.s[3]                                                                         │
       │0x4009d8 <Montmul512+88>        umull2 v18.2d, v14.4s, v7.s[3]                                                                         │
       │0x4009dc <Montmul512+92>        umull2 v19.2d, v12.4s, v7.s[3]                                                                         │
       │0x4009e0 <Montmul512+96>        umull  v20.2d, v15.2s, v7.s[3]                                                                         │
       │0x4009e4 <Montmul512+100>       umull  v21.2d, v13.2s, v7.s[3]                                                                         │
       │0x4009e8 <Montmul512+104>       umull  v22.2d, v14.2s, v7.s[3]                                                                         │
       └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
    (gdb) print v16
    print v16
    No symbol "v16" in current context.

I haven't had any experience around debugging assembly codes, so maybe this question seems to be very simple for many folks.

Answer 1

You can also print vector registers from within gdb like in the examples below.

(gdb) p $v0
$101 = {d = {f = {1.2672947890318689e-279, 7.7486181465248912e-304}, u = {434317018741670663, 72340181461566213}, s = {434317018741670663, 72340181461566213}}, s = {
    f = {2.42644275e-35, 2.53914328e-35, 3.79131591e-37, 2.36942839e-38}, u = {100729607, 101122311, 50397957, 16843011}, s = {100729607, 101122311, 50397957, 
      16843011}}, h = {u = {775, 1537, 263, 1543, 773, 769, 259, 257}, s = {775, 1537, 263, 1543, 773, 769, 259, 257}}, b = {u = {7, 3, 1, 6, 7, 1, 7, 6, 5, 3, 1, 3, 
      3, 1, 1, 1}, s = {7, 3, 1, 6, 7, 1, 7, 6, 5, 3, 1, 3, 3, 1, 1, 1}}, q = {u = {0x01010103030103050607010706010307}, s = {0x01010103030103050607010706010307}}}

Print different lanes/elements:

(gdb) p $v0.q
$102 = {u = {0x01010103030103050607010706010307}, s = {0x01010103030103050607010706010307}}
(gdb) p $v0.d
$103 = {f = {1.2672947890318689e-279, 7.7486181465248912e-304}, u = {434317018741670663, 72340181461566213}, s = {434317018741670663, 72340181461566213}}
(gdb) p $v0.s
$104 = {f = {2.42644275e-35, 2.53914328e-35, 3.79131591e-37, 2.36942839e-38}, u = {100729607, 101122311, 50397957, 16843011}, s = {100729607, 101122311, 50397957, 
    16843011}}
(gdb) p $v0.q.s
$105 = {0x01010103030103050607010706010307}
(gdb) p $v0.d.s
$106 = {434317018741670663, 72340181461566213}
(gdb) p $v0.d.s[1]
$107 = 72340181461566213

In my experience using the -tui, layout asm, layout reg option tends to be crowded if you don't have very large monitors. So if you do the commands below in gdb you'll have a hard time seeing all the simd registers. I tend to use abbreviations since I'm lazy. Gdb will let you know when it doesn't understand which command you want.

(gdb) wh reg +1
(gdb) tu reg next

Answer 2

Try info vector for all Advanced SIMD registers (printed in various layouts), or info all-registers v16 for just the contents of v16.

Answer 3

ARMv7

And this is the ARMv7 behavior analogous to the ARMv8 mentioned at: https://stackoverflow.com/a/38538116/9160762 with QEMU v3.0.0 built from source user mode + GDB 8.2 Ubuntu 16.04.

After loading:

1.5, 2.5, 3.5, 4.5

into q0, we have:

(gdb) p $q0
$3 = {
  u8 = {[0] = 0, [1] = 0, [2] = 192, [3] = 63, [4] = 0, [5] = 0, [6] = 32, [7] = 64, [8] = 0, [9] = 0, [10] = 96, [11] = 64, [12] = 0, [13] = 0, [14] = 144, [15] = 64}, 
  u16 = {[0] = 0, [1] = 16320, [2] = 0, [3] = 16416, [4] = 0, [5] = 16480, [6] = 0, [7] = 16528}, 
  u32 = {[0] = 1069547520, [1] = 1075838976, [2] = 1080033280, [3] = 1083179008}, 
  u64 = {[0] = 4620693218751676416, [1] = 4652218416153755648}, 
  f32 = {[0] = 1.5, [1] = 2.5, [2] = 3.5, [3] = 4.5}, 
  f64 = {[0] = 8.0000018998980522, [1] = 1024.0002455711365}
}

and:

(gdb) p $q0.f32
$5 = {[0] = 1.5, [1] = 2.5, [2] = 3.5, [3] = 4.5}

Test setup.

Bug with info register

When I try to use info vector or info register in this setup (v7 or v8) as mentioned at https://stackoverflow.com/a/35552000/9160762 , there seems to be a bug where the floating point representation gets converted to integer, see: https://reverseengineering.stackexchange.com/questions/8992/floating-point-registers-on-arm/20623#20623

SVE

Not yet implemented on QEMU, see: How to assemble ARM SVE instructions with GNU GAS or LLVM and run it on QEMU?