-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable HwbpManual #541
base: master
Are you sure you want to change the base?
Enable HwbpManual #541
Conversation
e880b5b
to
769f08a
Compare
debug/gdbserver.py
Outdated
@@ -710,6 +715,7 @@ def test(self): | |||
self.gdb.p("$pc") | |||
assertRegex(output, r"[bB]reakpoint") | |||
assertIn("rot13 ", output) | |||
self.gdb.stepi() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need this stepi
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
riscv-tests/debug/programs/debug.c
Lines 65 to 68 in 7dfa49b
rot13(fox); | |
checksum ^= crc32a(fox, strlen(fox)); | |
rot13(fox); | |
checksum ^= crc32a(fox, strlen(fox)); |
According to the program, I think that the breakpoint should be hit 2 times at rot13, and then hit at crc32a and _exit sequentially. So stepi avoids hitting the rot13 breakpoint at the same position as main
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So stepi avoids hitting the rot13 breakpoint at the same position as main
I don't get it. What do you mean "at the same position as main" ? main and rot13 should have different addresses. When gdb issues a continue request it issues a single-step and then issues a real continue. The breakpoint at main should not be hit.
debug/gdbserver.py
Outdated
if value == tdata1: | ||
value = self.gdb.p("$tdata1") | ||
if value == tdata1 or \ | ||
(value >> (xlen-4) == 0x6 and \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
value >> (xlen-4) == 0x6
What is the purpose of this condition? If I read this right we explicitly ask for TYPE=2 trigger. How come we end up with TYPE=6?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The purpose is to be compatible with spec 1.0 and 0.13. On our hardware that supports spec 0.13, setting the TYPE to 2 trigger actually we end up with TYPE=6.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we instead just re-request type==6 if the resulting value of tdata1 is different? I believe this would enable us to support wide range of platforms in a more cleaner way.
4f5c95e
to
785eee0
Compare
785eee0
to
0f3a832
Compare
@aap-sc hello,I have made some modifications to support wide range of platforms. Could you please review it. |
Thanks, I agree that perform 2 separate calls (for type2 and type6) |
0f3a832
to
c7d1719
Compare
type_none = set_field(0, TDATA1_TYPE(self.hart.xlen), | ||
TDATA1_TYPE_NONE) | ||
if type_rb == type_match: | ||
maskmax_rb = tdata1_rb & MCONTROL_MASKMAX(self.hart.xlen) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd sugest passing the mask to use before the comparison of tdata1
and tdata1_rb
as an argument of set_manual_trigger()
@en-sc Passing both type_none and type_match as an argument of set_manual_trigger() ?Which parameter are you referring to as a function argument . |
Change-Id: I2ee8718f03d6e381369b7d3bb0222563789ed525