search

eclipse-cdt-cloud / cdt-gdb-adapter

CDT GDB Debug Adapter
Eclipse Public License 2.0
28 stars 40 forks source link

Update status of multi threads in Call Stack View #257

Closed bangdang1411 closed 1 year ago

bangdang1411 commented 1 year ago

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.

bangdang1411 commented 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.

jonahgraham commented 1 year ago

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.

jonahgraham commented 1 year ago

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

bangdang1411 commented 1 year ago

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.

jonahgraham commented 1 year ago

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.

bangdang1411 commented 1 year ago

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.

jonahgraham commented 1 year ago

@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 commented 1 year ago

@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.

bangdang1411 commented 1 year ago

The current commit only fixes for the bug that selects Resume 1 thread but all threads are Resuming.

bangdang1411 commented 1 year ago

I attached the log file when using this solution. Thank you. RH850_LogFile.txt