-
Notifications
You must be signed in to change notification settings - Fork 42
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
add the function to edit register value #199
Conversation
Can one of the admins verify this patch? |
Hi @QuocDoBV thanks for they PR. Unfortunately it looks like this version has some problems as the change is in the wrong file making the diff very large. Also the ECA check fails. Perhaps @quyettrinhrvc can advise on how to resolve ECA issue. |
Hi @jonahgraham thanks a lot for your information. |
Hi @jonahgraham, |
Hi, this looks good - we need some tests. @quyettrinhrvc wrote the register read tests here: cdt-gdb-adapter/src/integration-tests/var.spec.ts Lines 127 to 129 in 7ef1e92
The equivalent for setting variables is a little further down the file: cdt-gdb-adapter/src/integration-tests/var.spec.ts Lines 189 to 199 in 7ef1e92
|
Hi @jonahgraham, |
I don't see any failures in the integration.zip file you attached. I do see skipped tests, which is expected, some tests cannot be run on every machine. Rather than attach the machine readable xml file, you can provide the failed tests from the stdout, e.g. like this:
You need new tests to cover your new functionality. |
Please refer to this comment for a starting point on writing tests for this use case. |
Hi @jonahgraham, |
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 @QuocDoBV for writing the tests. That makes it possible for me to properly review the change now. Please find my detailed line comments. Feel free to ask any follow up questions as needed.
Hi @jonahgraham , |
Dear @jonahgraham, |
Dear @jonahgraham, |
Hi @QuocDoBV - as mentioned before please don't bother attaching xml files. The human readable output of the test is much more useful. Also if all the tests are passing I don't need to see anything, you can just tell me they all passed. |
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.
This is mostly fine - just needs some polishing and the missing test.
Dear @jonahgraham, |
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 will do the requested change.
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.
There is still a serious bug in this code. I am sorry I didn't see it before now. Consider the use case where a user modified a register which has the same name as a local variable (e.g. rax
).
Here is a log of the problem with my comments:
# VScode requests scopes, as you can see ref 1000 is for Local variables and 1001 is for registers
From client: scopes({"frameId":1000})
To client: {"seq":0,"type":"response","request_seq":17,"command":"scopes","success":true,"body":{"scopes":[{"name":"Local","variablesReference":1000,"expensive":false},{"name":"Registers","variablesReference":1001,"expensive":true}]}}
# Here VScode requests variables for reg 1000 (locals)...
From client: variables({"variablesReference":1000})
GDB command: 25 -stack-info-depth 100
GDB result: 25 done,depth="1"
GDB command: 26 -stack-list-variables --thread 1 --simple-values
GDB result: 26 done,variables=[{name="rax",type="int",value="1"}]
# ... and the adapter creates var4 for accessing local variable rax
GDB command: 27 -var-create --thread 1 --frame 0 - * "rax"
GDB result: 27 done,name="var4",numchild="0",value="1",type="int",thread-id="1",has_more="0"
# Here VScode resuests the registers
# eliding GDB responses for getting register names and values because they are very long
From client: variables({"variablesReference":1001})
GDB command: 28 -data-list-register-names --frame 0 --thread 1
GDB command: 29 -data-list-register-values --frame 0 --thread 1 x
To client: {"seq":0,"type":"response","request_seq":19,"command":"variables","success":true,"body":{"variables":[{"name":"rax","evaluateName":"$rax","value":"0x1","variablesReference":0}, # -- snip
# Here VSCode is trying to set the register rax
From client: setVariable({"variablesReference":1001,"name":"rax","value":"1234"})
GDB command: 30 -stack-info-depth 100
GDB result: 30 done,depth="1"
# But it is var4 that is assigned - which is the varobj for the local variable
GDB command: 31 -var-assign var4 1234
GDB result: 31 done,value="1234"
@QuocDoBV Please resolve this (and while at it you can add the comments covering the design decision to not delete the varobjs).
frame.frameId, | ||
frame.threadId, | ||
depth, | ||
args.name, |
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.
This varobj is stored in the varManager in a way that it indistinguishable from a local variable of the same name.
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 have fixed it.
PS Please create a test case for this usage scenario to make sure that it doesn't regress later. |
I have created test cases to cover it. |
Dear @jonahgraham, |
Thank you @QuocDoBV for the new code and for good new tests to keep it working into the future too. |
Currently, we only can edit local value. We cannot edit register value on variable view. So, we need to add the function to do it.