RISCV_TRIGGER on load/store data

234 views
Skip to first unread message

raghu ram

unread,
Jul 27, 2017, 7:46:14 AM7/27/17
to RISC-V Debug Group

Hi Tim,

     I am following riscv-debug_spec-0.11 version to set triggers on load/store data instead of address.
     But, for all commands like rwatch/watch, openocd is setting trigger on address only. 
    
    When I observe logic inside trigger_from_watchpoint function, I see there is no field which differentiates between address/data watchpoint
     
                                 File: src/target/riscv/riscv.c


         
 
    Then, how riscv-debug spec supports the data trigger and how to configure the following bit in tdata1 register to set a trigger on data.     




Thanks & Regards,
Ram

Tim Newsome

unread,
Jul 27, 2017, 4:22:43 PM7/27/17
to raghu ram, RISC-V Debug Group
You are right. I never implemented breakpoint/watchpoint support for triggering on data values. It's not even obvious to me what gdb command you'd run to even specify that.
Assuming the values make it into OpenOCD's watchpoint structure, adding support should be fairly straightforward.

Can you open an issue for this at https://github.com/riscv/riscv-openocd/issues ?
I probably won't get to it any time soon, but if anybody is interested in contributing, this would be a great starter project.

Tim

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/3d76fc61-bad8-4b48-8249-16c8d5f8588e%40groups.riscv.org.

Sober Liu

unread,
Jul 27, 2017, 10:48:24 PM7/27/17
to Tim Newsome, raghu ram, RISC-V Debug Group

+1.

For watch point, we don’t implement this kind of trigger, and I don’t see gdb (in target remote mode) send such command to stub.

I am not 100% sure about how gdb-server works in this point.

 

From: Tim Newsome [mailto:t...@sifive.com]
Sent: Friday, July 28, 2017 4:23 AM
To: raghu ram <raghura...@gmail.com>
Cc: RISC-V Debug Group <de...@groups.riscv.org>
Subject: Re: [debug] RISCV_TRIGGER on load/store data

 

You are right. I never implemented breakpoint/watchpoint support for triggering on data values. It's not even obvious to me what gdb command you'd run to even specify that.

Assuming the values make it into OpenOCD's watchpoint structure, adding support should be fairly straightforward.

 

Can you open an issue for this at https://github.com/riscv/riscv-openocd/issues ?

I probably won't get to it any time soon, but if anybody is interested in contributing, this would be a great starter project.

 

Tim

On Thu, Jul 27, 2017 at 4:46 AM, raghu ram <raghura...@gmail.com> wrote:

 

Hi Tim,

 

     I am following riscv-debug_spec-0.11 version to set triggers on load/store data instead of address.

     But, for all commands like rwatch/watch, openocd is setting trigger on address only. 

    

    When I observe logic inside trigger_from_watchpoint function, I see there is no field which differentiates between address/data watchpoint

     

                                 File: src/target/riscv/riscv.c

 

         

 

    Then, how riscv-debug spec supports the data trigger and how to configure the following bit in tdata1 register to set a trigger on data.     

 

 

 

Thanks & Regards,

Ram

--

You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

 

--

You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.


To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

raghu ram

unread,
Jul 31, 2017, 2:08:31 PM7/31/17
to Sober Liu, Tim Newsome, RISC-V Debug Group
Thanks for the quick reply.

I also have a doubt on multihart debugging.
I see that there are some recent changes in riscv.c to support multihart, but I'm wondering how to specify the intended thread for debugging through gdb. Is there any list of instructions/steps to know how to do that.

One more question is, the 0.11 debug spec says that we can debug multiple harts simulataneously. Does it mean we can set software breakpoints/ triggers to both harts and wait for the core to hit them. If that is the case, as we have only 1 SETHALTNOT register which is common for both harts, which Hartid the debug rom will update into SETHALTNOT register.

Thanks & Regards,
Ram

Tim Newsome

unread,
Jul 31, 2017, 5:55:49 PM7/31/17
to raghu ram, Sober Liu, RISC-V Debug Group

On Mon, Jul 31, 2017 at 11:08 AM, raghu ram <raghura...@gmail.com> wrote:

I also have a doubt on multihart debugging.
I see that there are some recent changes in riscv.c to support multihart, but I'm wondering how to specify the intended thread for debugging through gdb. Is there any list of instructions/steps to know how to do that.

With the current OpenOCD implementation you have 2 options:

You can connect one gdb process per hart. I haven’t actually done that yet but it supposedly works.

You can use the -rtos riscv hack, where OpenOCD will pretend to gdb that there’s an RTOS running, and each hart is exposed to gdb as a thread. In OpenOCD’s config this looks like this:

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME -rtos riscv

Then in gdb you can use info threads and thread N to see a list of harts and to switch between them.

One more question is, the 0.11 debug spec says that we can debug multiple harts simulataneously. Does it mean we can set software breakpoints/ triggers to both harts and wait for the core to hit them.

You can set breakpoints/triggers on each hart independently. (Software breakpoints are shared if both harts are executing the same code.) There is no facility for automatically halting one hart because another one hit a breakpoint.

If that is the case, as we have only 1 SETHALTNOT register which is common for both harts, which Hartid the debug rom will update into SETHALTNOT register.

When 2 harts are halted, they will both write their own hartid to SETHALTNOT. Assuming you have some way of serializing the writes, this should set the appropriate bits

Please use the 0.13 spec if you can. Nobody will be writing new tools to work with 0.11, although I’ll likely be supporting it with OpenOCD for some time because SiFive has silicon that implements it.

Tim


Thanks & Regards,
Ram


--

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.


To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

​
Reply all
Reply to author
Forward
0 new messages