why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?

why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?

[庄秋彬]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

Hi,

I use gdb with openocd to debug a riscv board, and found that when set $pc=xxx(a non-zero value) in gdb, gdb would first read the address 0x0, which caused an error on this riscv device.
Is there any documentation or suggestions for reading the source code to solve this problem? 
Thanks


This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking. 
 
本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。

Re: why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?

[庄秋彬]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

Some debug info on another board that allows read address 0, shows that gdb did read address 0 when set pc:

(gdb) set debug remote 1
(gdb) p $pc
$2 = (void (*)()) 0xffffffff80003e4a
(gdb) set $pc=0xffffffff80003e4a
[remote] Sending packet: $m0,2#fb
[remote] Packet received: 7310
[remote] Sending packet: $m2,2#fd
[remote] Packet received: 4030
[remote] Sending packet: $g#67
[remote] Packet received: 000000000000000014ed5c80ffffffffd03d2081ffffffff78a13181ffffffff40c22081ffffffff40d71e7ed8ffffff00000000000000006036e080ffffffffe03d2081ffffffff00000000000000000000000000000000f872f180ffffffff000000000000000040c22081ffffffff010000000000000000a050fdd8ffffff0000000000000000454d495400000000f8c13181ffffffffd0c33181ffffffff000000000000000018c03181ffffffff08008080ffffffff7f000000000000003850034000000000987605400000000000000000000000000000000000000000fe030000000000000000000000000000ebdecce0000000000000000000000000 [16 bytes omitted]
[remote] Sending packet: $m0,2#fb
[remote] Packet received: 7310
[remote] Sending packet: $m2,2#fd
[remote] Packet received: 4030
> From: "庄秋彬"<mark.zhuang@spacemit.com>
> Date:  Wed, Jul 19, 2023, 15:59
> Subject:  why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?
> To: "gdb@sourceware.org"<gdb@sourceware.org>
> Hi,
> 
> I use gdb with openocd to debug a riscv board, and found that when set $pc=xxx(a non-zero value) in gdb, gdb would first read the address 0x0, which caused an error on this riscv device.
> Is there any documentation or suggestions for reading the source code to solve this problem? 
> Thanks


This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking. 
 
本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。

Re: why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?

[Tom Tromey]

>>>>> 庄秋彬  <mark.zhuang@spacemit.com> writes:

Sorry about the delay on this.

> I use gdb with openocd to debug a riscv board, and found that when set
> $pc=xxx(a non-zero value) in gdb, gdb would first read the address
> 0x0, which caused an error on this riscv device.  Is there any
> documentation or suggestions for reading the source code to solve this
> problem? 


I don't think so.  Reading 0x0 when trying to set $pc is unexpected to
me at least.  I'd normally approach this by debugging gdb to try to
understand why it is happening.

Tom

Re: why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?

[庄秋彬]

[-- Attachment #1: Type: text/plain, Size: 11231 bytes --]

Hi Tom,

Thank you for your reply, I'm trying to debug it.

I use qemu-riscv64 to run a program, then use riscv-gdb to debug it, riscv-gdb show that it send package "$m0,2#fb" to qemu, the full log is:
(riscv-gdb) target remote localhost:1235
Remote debugging using localhost:1235
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0000000000010528 in ?? ()
(riscv-gdb) set debug remote 1
(riscv-gdb) set $pc=0x10528
[remote] Sending packet: $m0,2#fb
[remote] Received Ack
[remote] Packet received: E14
[remote] Sending packet: $g#67
[remote] Received Ack
[remote] Packet received: 00000000000000000000000000000000900280004000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 [16 bytes omitted]
[remote] Sending packet: $m10528,4#cd
[remote] Received Ack
[remote] Packet received: ef00e002
[remote] Sending packet: $m10524,4#c9
[remote] Received Ack
[remote] Packet received: f5b70000
[remote] Sending packet: $m0,2#fb
[remote] Received Ack
[remote] Packet received: E14


Then I use gdb(x86-gdb) to debug this riscv-gdb, the package "$m0,2#fb" comes from some code about riscv frame, full log is:

Thread 1 "riscv64-unknown" hit Breakpoint 2, remote_target::putpkt_binary (this=0xf399d0, buf=<optimized out>, cnt=<optimized out>)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9602
9602        /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c: No such file or directory.
(gdb) bt
#0  remote_target::putpkt_binary (this=0xf399d0, buf=<optimized out>, cnt=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9602
#1  0x00000000006b7d38 in remote_target::putpkt (buf=0xfaeac0 "m0,2", this=0xf399d0) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9516
#2  remote_target::putpkt (buf=..., this=0xf399d0) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:907
#3  remote_target::remote_read_bytes_1 (this=this@entry=0xf399d0, memaddr=<optimized out>, memaddr@entry=0, myaddr=myaddr@entry=0x7fffffffd968 "\204\036f", len_units=len_units@entry=2,
    unit_size=unit_size@entry=1, xfered_len_units=xfered_len_units@entry=0x7fffffffd8f8) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9190
#4  0x00000000006b7f91 in remote_target::remote_read_bytes (this=0xf399d0, memaddr=0, myaddr=0x7fffffffd968 "\204\036f", len=2, unit_size=1, xfered_len=0x7fffffffd8f8)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9315
#5  0x000000000072cbcf in raw_memory_xfer_partial (ops=ops@entry=0xf399d0, readbuf=readbuf@entry=0x7fffffffd968 "\204\036f", writebuf=writebuf@entry=0x0, memaddr=memaddr@entry=0, len=2,
    xfered_len=xfered_len@entry=0x7fffffffd8f8) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:1514
#6  0x000000000072cd1f in memory_xfer_partial_1 (ops=ops@entry=0xf399d0, object=object@entry=TARGET_OBJECT_MEMORY, readbuf=readbuf@entry=0x7fffffffd968 "\204\036f", writebuf=writebuf@entry=0x0,
    memaddr=memaddr@entry=0, len=len@entry=2, xfered_len=0x7fffffffd8f8) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:1645
#7  0x000000000072cf9a in memory_xfer_partial (xfered_len=0x7fffffffd8f8, len=2, memaddr=0, writebuf=0x0, readbuf=0x7fffffffd968 "\204\036f", object=TARGET_OBJECT_MEMORY, ops=0xf399d0)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:1674
#8  target_xfer_partial (ops=0xf399d0, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x7fffffffd968 "\204\036f", writebuf=0x0, offset=0, len=<optimized out>, xfered_len=0x7fffffffd8f8)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:1731
#9  0x000000000072d3a9 in target_read_partial (xfered_len=0x7fffffffd8f8, len=2, offset=0, buf=0x7fffffffd968 "\204\036f", annex=0x0, object=TARGET_OBJECT_MEMORY, ops=0xf399d0)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:2024
#10 target_read (ops=0xf399d0, object=object@entry=TARGET_OBJECT_MEMORY, annex=annex@entry=0x0, buf=buf@entry=0x7fffffffd968 "\204\036f", offset=offset@entry=0, len=len@entry=2)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:2024
#11 0x000000000072d416 in target_read_memory (memaddr=memaddr@entry=0, myaddr=myaddr@entry=0x7fffffffd968 "\204\036f", len=len@entry=2)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.h:1394
#12 0x00000000006c0de8 in riscv_insn::fetch_instruction (gdbarch=gdbarch@entry=0xf83870, addr=0, len=len@entry=0x7fffffffd9e0)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1664
#13 0x00000000006c0ee8 in riscv_insn::decode (this=0x7fffffffd9e0, gdbarch=0xf83870, pc=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1693
#14 0x00000000006c187c in riscv_scan_prologue (gdbarch=0xf83870, start_pc=<optimized out>, end_pc=100, cache=0xe9bd20) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1873
#15 0x00000000006c1fdc in riscv_frame_cache (this_frame=0xe9bc60, this_cache=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:3340
#16 0x00000000006c2139 in riscv_frame_this_id (this_frame=<optimized out>, prologue_cache=<optimized out>, this_id=0xe9bcc0)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:3392
#17 0x00000000005bf142 in compute_frame_id (fi=0xe9bc60) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/frame.c:583
#18 0x00000000005bf3cf in get_frame_id (fi=0xe9bc60) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/frame.c:626
#19 0x000000000078919a in value_assign (toval=0xf80340, fromval=0xf18890) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/valops.c:1103
#20 0x000000000059e5fd in expression::evaluate (this=0xf8cf40, expect_type=0x0, noside=EVAL_NORMAL) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/eval.c:101
#21 0x0000000000678e98 in set_command (exp=<optimized out>, from_tty=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/printcmd.c:1520
#22 0x00000000004eeba8 in cmd_func (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/cli/cli-decode.c:2514
#23 0x00000000007486ae in execute_command (p=<optimized out>, p@entry=0xe4c6f0 "set $pc=0x10528", from_tty=1) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/top.c:702
#24 0x00000000005a45bc in command_handler (command=0xe4c6f0 "set $pc=0x10528") at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:597
#25 0x00000000005a48bb in command_line_handler (rl=...) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:800
#26 0x00000000005a4ead in gdb_rl_callback_handler (rl=0xf887d0 "set $pc=0x10528") at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:229
#27 0x000000000080f7a0 in rl_callback_read_char () at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/readline/readline/callback.c:281
#28 0x00000000005a39fe in gdb_rl_callback_read_char_wrapper_noexcept () at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:187
#29 0x00000000005a4d9e in gdb_rl_callback_read_char_wrapper (client_data=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:203
#30 0x00000000005a3810 in stdin_event_handler (error=<optimized out>, client_data=0xe47f80) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:524
#31 0x00000000008b5665 in gdb_wait_for_event (block=block@entry=1) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdbsupport/event-loop.cc:700
#32 0x00000000008b573d in gdb_wait_for_event (block=1) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdbsupport/event-loop.cc:596
#33 gdb_do_one_event () at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdbsupport/event-loop.cc:237
#34 0x000000000062c765 in start_event_loop () at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/main.c:421
#35 captured_command_loop () at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/main.c:481
#36 0x000000000062dcd5 in captured_main (data=data@entry=0x7fffffffe180) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/main.c:1351
#37 gdb_main (args=args@entry=0x7fffffffe1a0) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/main.c:1366
#38 0x000000000042f625 in main (argc=<optimized out>, argv=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/gdb.c:32

I'm not familiar with gdb, so it will take some time to figure out exactly what's going on.


> From:"Tom Tromey"<tom@tromey.com>
> Date:Thu, Jul 27, 2023, 00:09
> Subject:Re: why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?
> To:"庄秋彬"<mark.zhuang@spacemit.com>
> Cc:"gdb@sourceware.org"<gdb@sourceware.org>
> >>>>> 庄秋彬  <mark.zhuang@spacemit.com> writes:
> 
> Sorry about the delay on this.
> 
> > I use gdb with openocd to debug a riscv board, and found that when set
> > $pc=xxx(a non-zero value) in gdb, gdb would first read the address
> > 0x0, which caused an error on this riscv device.  Is there any
> > documentation or suggestions for reading the source code to solve this
> > problem? 
> 
> 
> I don't think so.  Reading 0x0 when trying to set $pc is unexpected to
> me at least.  I'd normally approach this by debugging gdb to try to
> understand why it is happening.
> 
> Tom


This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking. 
 
本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。

RE: why gdb try to read address 0x0 when I set $pc，how to suppress this behavior?

[Torbjorn SVENSSON]

Hello,

I think the interesting frames are:

#12 0x00000000006c0de8 in riscv_insn::fetch_instruction (gdbarch=gdbarch@entry=0xf83870, addr=0, len=len@entry=0x7fffffffd9e0)
    at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1664
#13 0x00000000006c0ee8 in riscv_insn::decode (this=0x7fffffffd9e0, gdbarch=0xf83870, pc=<optimized out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1693
#14 0x00000000006c187c in riscv_scan_prologue (gdbarch=0xf83870, start_pc=<optimized out>, end_pc=100, cache=0xe9bd20) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1873

Before you do anything else, I would suggest that you rebuild riscv-gdb with debug symbols and without optimization ("-O0 -ggdb" for clang/gcc) as it will make debugging much easier. 

Then I would either run it in a native gdb, as Tom suggested, or instrument the code with some additional printf statements to show the content of some important variables.
Particular interesting is the content of "next_pc", "cur_pc", "start_pc" and "end_pc" in the for-loop in riscv_scan_prologue.

Happy hacking! :)

Regards,
Torbjörn

> -----Original Message-----
> From: Gdb <gdb-bounces+torbjorn.svensson=st.com@sourceware.org> On
> Behalf Of ???
> Sent: den 27 juli 2023 17:51
> To: Tom Tromey <tom@tromey.com>
> Cc: gdb <gdb@sourceware.org>
> Subject: Re: why gdb try to read address 0x0 when I set $pc，how to
> suppress this behavior?
> 
> Hi Tom,
> 
> Thank you for your reply, I'm trying to debug it.
> 
> I use qemu-riscv64 to run a program, then use riscv-gdb to debug it, riscv-gdb
> show that it send package "$m0,2#fb" to qemu, the full log is:
> (riscv-gdb) target remote localhost:1235
> Remote debugging using localhost:1235
> warning: No executable has been specified and target does not support
> determining executable automatically.  Try using the "file" command.
> 0x0000000000010528 in ?? ()
> (riscv-gdb) set debug remote 1
> (riscv-gdb) set $pc=0x10528
> [remote] Sending packet: $m0,2#fb
> [remote] Received Ack
> [remote] Packet received: E14
> [remote] Sending packet: $g#67
> [remote] Received Ack
> [remote] Packet received:
> 00000000000000000000000000000000900280004000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000
> 00000000000000000000000000000000000000000000000000000000000000
> 0000000000000000 [16 bytes omitted]
> [remote] Sending packet: $m10528,4#cd
> [remote] Received Ack
> [remote] Packet received: ef00e002
> [remote] Sending packet: $m10524,4#c9
> [remote] Received Ack
> [remote] Packet received: f5b70000
> [remote] Sending packet: $m0,2#fb
> [remote] Received Ack
> [remote] Packet received: E14
> 
> 
> Then I use gdb(x86-gdb) to debug this riscv-gdb, the package "$m0,2#fb"
> comes from some code about riscv frame, full log is:
> 
> Thread 1 "riscv64-unknown" hit Breakpoint 2, remote_target::putpkt_binary
> (this=0xf399d0, buf=<optimized out>, cnt=<optimized out>)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9602
> 9602        /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:
> No such file or directory.
> (gdb) bt
> #0  remote_target::putpkt_binary (this=0xf399d0, buf=<optimized out>,
> cnt=<optimized out>) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/remote.c:9602
> #1  0x00000000006b7d38 in remote_target::putpkt (buf=0xfaeac0 "m0,2",
> this=0xf399d0) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/remote.c:9516
> #2  remote_target::putpkt (buf=..., this=0xf399d0) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/remote.c:907
> #3  remote_target::remote_read_bytes_1 (this=this@entry=0xf399d0,
> memaddr=<optimized out>, memaddr@entry=0,
> myaddr=myaddr@entry=0x7fffffffd968 "\204\036f",
> len_units=len_units@entry=2,
>     unit_size=unit_size@entry=1,
> xfered_len_units=xfered_len_units@entry=0x7fffffffd8f8) at
> /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9190
> #4  0x00000000006b7f91 in remote_target::remote_read_bytes
> (this=0xf399d0, memaddr=0, myaddr=0x7fffffffd968 "\204\036f", len=2,
> unit_size=1, xfered_len=0x7fffffffd8f8)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/remote.c:9315
> #5  0x000000000072cbcf in raw_memory_xfer_partial
> (ops=ops@entry=0xf399d0, readbuf=readbuf@entry=0x7fffffffd968
> "\204\036f", writebuf=writebuf@entry=0x0, memaddr=memaddr@entry=0,
> len=2,
>     xfered_len=xfered_len@entry=0x7fffffffd8f8) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/target.c:1514
> #6  0x000000000072cd1f in memory_xfer_partial_1
> (ops=ops@entry=0xf399d0,
> object=object@entry=TARGET_OBJECT_MEMORY,
> readbuf=readbuf@entry=0x7fffffffd968 "\204\036f",
> writebuf=writebuf@entry=0x0,
>     memaddr=memaddr@entry=0, len=len@entry=2,
> xfered_len=0x7fffffffd8f8) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/target.c:1645
> #7  0x000000000072cf9a in memory_xfer_partial (xfered_len=0x7fffffffd8f8,
> len=2, memaddr=0, writebuf=0x0, readbuf=0x7fffffffd968 "\204\036f",
> object=TARGET_OBJECT_MEMORY, ops=0xf399d0)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:1674
> #8  target_xfer_partial (ops=0xf399d0, object=TARGET_OBJECT_MEMORY,
> annex=0x0, readbuf=0x7fffffffd968 "\204\036f", writebuf=0x0, offset=0,
> len=<optimized out>, xfered_len=0x7fffffffd8f8)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:1731
> #9  0x000000000072d3a9 in target_read_partial (xfered_len=0x7fffffffd8f8,
> len=2, offset=0, buf=0x7fffffffd968 "\204\036f", annex=0x0,
> object=TARGET_OBJECT_MEMORY, ops=0xf399d0)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:2024
> #10 target_read (ops=0xf399d0,
> object=object@entry=TARGET_OBJECT_MEMORY,
> annex=annex@entry=0x0, buf=buf@entry=0x7fffffffd968 "\204\036f",
> offset=offset@entry=0, len=len@entry=2)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.c:2024
> #11 0x000000000072d416 in target_read_memory
> (memaddr=memaddr@entry=0, myaddr=myaddr@entry=0x7fffffffd968
> "\204\036f", len=len@entry=2)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/target.h:1394
> #12 0x00000000006c0de8 in riscv_insn::fetch_instruction
> (gdbarch=gdbarch@entry=0xf83870, addr=0, len=len@entry=0x7fffffffd9e0)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-
> tdep.c:1664
> #13 0x00000000006c0ee8 in riscv_insn::decode (this=0x7fffffffd9e0,
> gdbarch=0xf83870, pc=<optimized out>) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1693
> #14 0x00000000006c187c in riscv_scan_prologue (gdbarch=0xf83870,
> start_pc=<optimized out>, end_pc=100, cache=0xe9bd20) at
> /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:1873
> #15 0x00000000006c1fdc in riscv_frame_cache (this_frame=0xe9bc60,
> this_cache=<optimized out>) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/riscv-tdep.c:3340
> #16 0x00000000006c2139 in riscv_frame_this_id (this_frame=<optimized
> out>, prologue_cache=<optimized out>, this_id=0xe9bcc0)
>     at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/riscv-
> tdep.c:3392
> #17 0x00000000005bf142 in compute_frame_id (fi=0xe9bc60) at
> /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/frame.c:583
> #18 0x00000000005bf3cf in get_frame_id (fi=0xe9bc60) at /toolchain/riscv-
> gnu-toolchain/build_gcc12/../gdb/gdb/frame.c:626
> #19 0x000000000078919a in value_assign (toval=0xf80340,
> fromval=0xf18890) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/valops.c:1103
> #20 0x000000000059e5fd in expression::evaluate (this=0xf8cf40,
> expect_type=0x0, noside=EVAL_NORMAL) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/eval.c:101
> #21 0x0000000000678e98 in set_command (exp=<optimized out>,
> from_tty=<optimized out>) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/printcmd.c:1520
> #22 0x00000000004eeba8 in cmd_func (cmd=<optimized out>,
> args=<optimized out>, from_tty=<optimized out>) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/cli/cli-decode.c:2514
> #23 0x00000000007486ae in execute_command (p=<optimized out>,
> p@entry=0xe4c6f0 "set $pc=0x10528", from_tty=1) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/top.c:702
> #24 0x00000000005a45bc in command_handler (command=0xe4c6f0 "set
> $pc=0x10528") at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/event-top.c:597
> #25 0x00000000005a48bb in command_line_handler (rl=...) at
> /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:800
> #26 0x00000000005a4ead in gdb_rl_callback_handler (rl=0xf887d0 "set
> $pc=0x10528") at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/event-top.c:229
> #27 0x000000000080f7a0 in rl_callback_read_char () at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/readline/readline/callback.c:281
> #28 0x00000000005a39fe in gdb_rl_callback_read_char_wrapper_noexcept
> () at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/event-top.c:187
> #29 0x00000000005a4d9e in gdb_rl_callback_read_char_wrapper
> (client_data=<optimized out>) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/event-top.c:203
> #30 0x00000000005a3810 in stdin_event_handler (error=<optimized out>,
> client_data=0xe47f80) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/event-top.c:524
> #31 0x00000000008b5665 in gdb_wait_for_event (block=block@entry=1) at
> /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdbsupport/event-
> loop.cc:700
> #32 0x00000000008b573d in gdb_wait_for_event (block=1) at
> /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdbsupport/event-
> loop.cc:596
> #33 gdb_do_one_event () at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdbsupport/event-loop.cc:237
> #34 0x000000000062c765 in start_event_loop () at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/main.c:421
> #35 captured_command_loop () at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/main.c:481
> #36 0x000000000062dcd5 in captured_main
> (data=data@entry=0x7fffffffe180) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/main.c:1351
> #37 gdb_main (args=args@entry=0x7fffffffe1a0) at /toolchain/riscv-gnu-
> toolchain/build_gcc12/../gdb/gdb/main.c:1366
> #38 0x000000000042f625 in main (argc=<optimized out>, argv=<optimized
> out>) at /toolchain/riscv-gnu-toolchain/build_gcc12/../gdb/gdb/gdb.c:32
> 
> I'm not familiar with gdb, so it will take some time to figure out exactly
> what's going on.
> 
> 
> > From:"Tom Tromey"<tom@tromey.com>
> > Date:Thu, Jul 27, 2023, 00:09
> > Subject:Re: why gdb try to read address 0x0 when I set $pc，how to
> suppress this behavior?
> > To:"庄秋彬"<mark.zhuang@spacemit.com>
> > Cc:"gdb@sourceware.org"<gdb@sourceware.org>
> > >>>>> 庄秋彬  <mark.zhuang@spacemit.com> writes:
> >
> > Sorry about the delay on this.
> >
> > > I use gdb with openocd to debug a riscv board, and found that when set
> > > $pc=xxx(a non-zero value) in gdb, gdb would first read the address
> > > 0x0, which caused an error on this riscv device.  Is there any
> > > documentation or suggestions for reading the source code to solve this
> > > problem?
> >
> >
> > I don't think so.  Reading 0x0 when trying to set $pc is unexpected to
> > me at least.  I'd normally approach this by debugging gdb to try to
> > understand why it is happening.
> >
> > Tom
> 
> 
> This message and any attachment are confidential and may be privileged or
> otherwise protected from disclosure. If you are not an intended recipient of
> this message, please delete it and any attachment from your system and
> notify the sender immediately by reply e-mail. Unintended recipients should
> not use, copy, disclose or take any action based on this message or any
> information contained in this message. Emails cannot be guaranteed to be
> secure or error free as they can be intercepted, amended, lost or destroyed,
> and you should take full responsibility for security checking.
> 
> 本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露
> 给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知
> 发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非
> 本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容
> ，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证
> 是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢
> 失或损坏，收件人需自行负责做好安全检查。