-
Notifications
You must be signed in to change notification settings - Fork 319
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
introduce execution status for riscv_program #964
introduce execution status for riscv_program #964
Conversation
Note to reviewers:
|
464fb8d
to
960a623
Compare
@JanMatCodasip , @timsifive could you take a look once again? |
960a623
to
f5bc52d
Compare
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.
Looks good overall.
f5bc52d
to
53e739d
Compare
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.
One last comment.
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.
Thank you for the changes, it looks fine overall. I have completed my review and don't expect to have any more major comments than what I have posted.
src/target/riscv/program.h
Outdated
typedef enum { | ||
RISCV_DBGBUF_EXEC_RESULT_NOT_EXECUTED, | ||
RISCV_DBGBUF_EXEC_RESULT_UNKNOWN, | ||
RISCV_DBGBUF_EXEC_RESULT_EXCEPTION, | ||
RISCV_DBGBUF_EXEC_RESULT_UNKNOWN_ERROR, | ||
RISCV_DBGBUF_EXEC_RESULT_SUCCESS | ||
} riscv_progbuf_exec_result_t; | ||
|
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.
Thank you for unifying the names (debug_buffer -> progbuf) in many places in the code.
One last nitpick - RISCV_DBGBUF_*
items in this enum can be renamed to RISCV_PROGBUF_*
, too.
typedef enum { | |
RISCV_DBGBUF_EXEC_RESULT_NOT_EXECUTED, | |
RISCV_DBGBUF_EXEC_RESULT_UNKNOWN, | |
RISCV_DBGBUF_EXEC_RESULT_EXCEPTION, | |
RISCV_DBGBUF_EXEC_RESULT_UNKNOWN_ERROR, | |
RISCV_DBGBUF_EXEC_RESULT_SUCCESS | |
} riscv_progbuf_exec_result_t; | |
typedef enum { | |
RISCV_PROGBUF_EXEC_RESULT_NOT_EXECUTED, | |
RISCV_PROGBUF_EXEC_RESULT_UNKNOWN, | |
RISCV_PROGBUF_EXEC_RESULT_EXCEPTION, | |
RISCV_PROGBUF_EXEC_RESULT_UNKNOWN_ERROR, | |
RISCV_PROGBUF_EXEC_RESULT_SUCCESS | |
} riscv_progbuf_exec_result_t; | |
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.
strange, I though I did that ...
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.
Random comment: It is much easier to review changes if you make a separate PR for renaming a bunch of stuff without changing any functionality.
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.
Random comment: It is much easier to review changes if you make a separate PR for renaming a bunch of stuff without changing any functionality.
I moved these renames to a separate change set specifically to simplify the review. If this is still inconvenient, I can factor-out this in a separate MR.
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.
@timsifive I've splitted the whole change set into 2 distinct commits: one with functional changes the other is with the rename of dbgbuf->progbuf
. I've tested them separately. If necessary, I can move the second changeset to a separate MR.
@JanMatCodasip : addressed.
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.
Thanks.
src/target/riscv/riscv-013.c
Outdated
unsigned int abstractcs_err; | ||
if (execute_abstract_command(target, command, &abstractcs_err) != ERROR_OK) |
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 fully agree that errors should always be taken into account. That however does not mean that the caller of execute_abstract_command()
must always introspect the detailed cause of the error (cmderr) :-)
After thinking about it more, I believe it would be good to have 4 distinct return codes for execute_abstract_command():
- (1)
ERROR_OK
- Command succeeded. In this case the caller needs not look at cmderr (because cmderr is guaranteed to be 0). - (2)
ERROR_CMD_FAILED
(or similar name) - Command was executed but failed due to cmderr!=0. The caller can look at cmderr to determine the actual failure reason, if it wishes, but it does not need to do so. All depends on the caller's situation, and how detailed information about the error it needs to have. - (3)
ERROR_FAIL
- During the execution of the command, the DMI read or write operation failed. The target (or the connection to it) is seriously broken. The value in cmderr is irrelevant in this case. - (4)
ERROR_TIMEOUT_REACHED
- Timeout occurred. The value in cmderr is not relevant in this case, either.
At the moment, cases (2) and (3) is merged into one ERROR_FAIL return code. It would be good to split it because those are two different outcomes. Please, let me know if you have similar or different opinion. But no need to make the changes directly in this merge request. It would be good to agree on the strategy.
Based on the above, I still believe the third argument of execute_abstract_command() should be made optional. The caller should detect the overall status (1) - (4) through the return code. And only in case of (2), the cmderr can be introspected, but it is not mandatory to do so in all cases.
If there are lot's of cases when we don't want to introspect the detailed cause, then I agree that it may be better to return generic error-codes with |
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.
From my point of view:
-
- There is one last open thread (introduce execution status for riscv_program #964 (comment)) with cosmetic rename stuff.
-
- This pull request should be rebased (and conflicts solved).
After that I consider it ready for merge. Thanks.
5fb71bf
to
0712489
Compare
rebased and addressed all comments. @timsifive , @JanMatCodasip could you please take a look? |
0712489
to
d085c8e
Compare
d085c8e
to
a49b707
Compare
a49b707
to
b5196c1
Compare
Note to reviewers: the latest update is just a squash of |
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.
Looks good, thank you.
Change-Id: I3b283b49dea88a6f3d2159be3c9f6c6da604aa9e Signed-off-by: Parshintsev Anatoly <anatoly.parshintsev@syntacore.com>
Change-Id: I29e2192d5ce9d0f13010d8a09bd4ef50f5c8844b Signed-off-by: Parshintsev Anatoly <anatoly.parshintsev@syntacore.com>
b5196c1
to
aded275
Compare
@timsifive , @JanMatCodasip there was a small merge conflict with recently committed #978 (in riscv013_clear_abstract_error) . I've resolved it. Can we merge this one? |
@timsifive, @JanMatCodasip gentle ping. Also @en-sc could you please take a look? |
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.
LGTM
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.
Looks good to me, thank you.
This commit addresses #933
Change-Id: I318d5fd6af3a17d1c1099401427ca80ffbec0007