-
Notifications
You must be signed in to change notification settings - Fork 521
[debug] Support mcontrol and mcontrol6 based on HwbpManual #541
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
base: master
Are you sure you want to change the base?
Conversation
e880b5b to
769f08a
Compare
debug/gdbserver.py
Outdated
| 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
debug/gdbserver.py
Outdated
| 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()
49f4f2e to
1cd0669
Compare
|
Changes to resolve the following issues:
@en-sc could you please take a look? |
1cd0669 to
e7c4576
Compare
* support mcontrol6 in HwbpManual * test non-zero maskmax is supported for mcontrol
e7c4576 to
72af2b2
Compare
|
I want to ignore the [Line too long (81/80) ](gdbserver.py:854:0: C0301: Line too long (81/80) (line-too-long)) |
Change-Id: I2ee8718f03d6e381369b7d3bb0222563789ed525