Closed bangdang1411 closed 1 year ago
Hi @jonahgraham-san, This is the first solution to fix some issues when debugging with multiple cores devices. I am not sure that we can use it. Anyway, I think we can discuss more in this PR. Please help me take a look at it and give me your comment. Thank you.
Can you provide a reproducible test that demonstrates this? Ideally as an integration test, but if not at least as a step-by-step test, or if even that is impossible, some MI/DAP logs that show the problem.
There is multithread that you can use as a starting point for a test.
PS This change has caused a bunch of test failures - see https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/actions/runs/4283245156/jobs/7465169867
Can you provide a reproducible test that demonstrates this? Ideally as an integration test, but if not at least as a step-by-step test, or if even that is impossible, some MI/DAP logs that show the problem.
There is multithread that you can use as a starting point for a test.
I have mentioned you in the Jira ticket. Please help me see the document that describes the solution and the log file of it. Thank you.
I have mentioned you in the Jira ticket.
This is an open source project and should operate in the open. Please provide details accessible to all.
It includes some information of renesas-gdb-adapter. Do you think it need to accessible by everyone? I think I need to prepare some information before push it in Github. Thank you.
@bangdang1411, I think my previous comment summed it up best:
Can you provide a reproducible test that demonstrates this? Ideally as an integration test, but if not at least as a step-by-step test, or if even that is impossible, some MI/DAP logs that show the problem.
It is fine to mention the renesas-gdb-adapter, but it would be best to have a test case that doesn't rely on it.
@bangdang1411, I think my previous comment summed it up best:
Can you provide a reproducible test that demonstrates this? Ideally as an integration test, but if not at least as a step-by-step test, or if even that is impossible, some MI/DAP logs that show the problem.
It is fine to mention the renesas-gdb-adapter, but it would be best to have a test case that doesn't rely on it.
Sorry, I am investigating the reason that make the test in Linux is failed. Additionally, I am writing the integration test for it but not completed for now. You can see my idea first until I can commit the test. Thank you.
The current commit only fixes for the bug that selects Resume 1 thread but all threads are Resuming.
I attached the log file when using this solution. Thank you. RH850_LogFile.txt
For multiple cores debugging, the state of cores is not updated correctly with the state in the GDB server. Cannot use "Resume" or "Suspend" button in case of multiple cores debugging. That has not happened in cdt-amalgamator. This solution refers to cdt-amalgamator repository.
Root cause: Call Stack View does not update the state RUNNING if the process Initialize is not completed. cdt-gdb-adapter does not support sending "ContinuedEvent" when GDB returns async message "running"
Solution: Return Continues Response with the arg "allThreadsContinued" is 'false', which makes all threads not set to "RUNNING" state. Send ContinuedEvent when handling async message "running" from the GDB server. Remove the condition that does not send StoppedEvent if the process Initialize is not completed.