Reputation: 1
In the initialization code of ARMv8, I intend to use the memset function to initialize the BSS segment. However, when reaching a certain line of the memset function, the PC pointer suddenly points to a strange address and executes. Below is the bss clear code:
// Zero the bss
ldr x0, =__bss_start__ // Start of block
mov x1, #0 // Fill value
ldr x2, =__bss_end__ // End of block
sub x2, x2, x0 // Length of block
bl memset
When I use gdb to debug in memset, it works fine before 0x7e5f4c:
(gdb) disassemble
Dump of assembler code for function memset:
0x00000000007e5ec0 <+0>: dup v0.16b, w1
0x00000000007e5ec4 <+4>: add x4, x0, x2
0x00000000007e5ec8 <+8>: cmp x2, #0x60
0x00000000007e5ecc <+12>: b.hi 0x7e5f44 <memset+132> // b.pmore
0x00000000007e5ed0 <+16>: cmp x2, #0x10
0x00000000007e5ed4 <+20>: b.cs 0x7e5f14 <memset+84> // b.hs, b.nlast
0x00000000007e5ed8 <+24>: mov x1, v0.d[0]
0x00000000007e5edc <+28>: tbz w2, #3, 0x7e5ef0 <memset+48>
0x00000000007e5ee0 <+32>: str x1, [x0]
0x00000000007e5ee4 <+36>: stur x1, [x4, #-8]
0x00000000007e5ee8 <+40>: ret
0x00000000007e5eec <+44>: nop
0x00000000007e5ef0 <+48>: tbz w2, #2, 0x7e5f00 <memset+64>
0x00000000007e5ef4 <+52>: str w1, [x0]
0x00000000007e5ef8 <+56>: stur w1, [x4, #-4]
0x00000000007e5efc <+60>: ret
0x00000000007e5f00 <+64>: cbz x2, 0x7e5f10 <memset+80>
0x00000000007e5f04 <+68>: strb w1, [x0]
0x00000000007e5f08 <+72>: tbz w2, #1, 0x7e5f10 <memset+80>
0x00000000007e5f0c <+76>: sturh w1, [x4, #-2]
0x00000000007e5f10 <+80>: ret
0x00000000007e5f14 <+84>: str q0, [x0]
0x00000000007e5f18 <+88>: tbnz w2, #6, 0x7e5f30 <memset+112>
0x00000000007e5f1c <+92>: stur q0, [x4, #-16]
0x00000000007e5f20 <+96>: tbz w2, #5, 0x7e5f2c <memset+108>
0x00000000007e5f24 <+100>: str q0, [x0, #16]
0x00000000007e5f28 <+104>: stur q0, [x4, #-32]
0x00000000007e5f2c <+108>: ret
0x00000000007e5f30 <+112>: str q0, [x0, #16]
0x00000000007e5f34 <+116>: stp q0, q0, [x0, #32]
0x00000000007e5f38 <+120>: stp q0, q0, [x4, #-32]
0x00000000007e5f3c <+124>: ret
0x00000000007e5f40 <+128>: nop
0x00000000007e5f44 <+132>: and w1, w1, #0xff
0x00000000007e5f48 <+136>: and x3, x0, #0xfffffffffffffff0
=> 0x00000000007e5f4c <+140>: str q0, [x0]
0x00000000007e5f50 <+144>: cmp x2, #0x100
0x00000000007e5f54 <+148>: ccmp w1, #0x0, #0x0, cs // cs = hs, nlast
0x00000000007e5f58 <+152>: b.eq 0x7e5f88 <memset+200> // b.none
0x00000000007e5f5c <+156>: sub x2, x4, x3
0x00000000007e5f60 <+160>: sub x3, x3, #0x10
0x00000000007e5f64 <+164>: sub x2, x2, #0x50
0x00000000007e5f68 <+168>: stp q0, q0, [x3, #32]
0x00000000007e5f6c <+172>: stp q0, q0, [x3, #64]!
0x00000000007e5f70 <+176>: subs x2, x2, #0x40
0x00000000007e5f74 <+180>: b.hi 0x7e5f68 <memset+168> // b.pmore
And the $pc value is still 0x7e5f4c, then I try to step to next instruction(stepi), but the PC pointer suddenly points to a strange address(0x7e1a00):
(gdb) si
0x00000000007e1a00 in spi_send (spi=0x7f6728 <spi0_resources>, num=<optimized out>, data=<optimized out>) at src/driver/spi_ae350.c:312
312 spi->info->xfer.tx_buf_limit = (uint8_t *)((long)(spi->info->xfer.tx_buf + num * 4));
Does anyone can help?
Upvotes: 0
Views: 101