when use memset() to clear .bss area, PC pointer suddenly points to a strange address

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

Answers (0)

Related Questions