Skip to content
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

There's no need to put conn_try_recv_intr to another thread. #7

Open
logic-wei opened this issue Jan 16, 2025 · 2 comments
Open

There's no need to put conn_try_recv_intr to another thread. #7

logic-wei opened this issue Jan 16, 2025 · 2 comments

Comments

@logic-wei
Copy link

logic-wei commented Jan 16, 2025

Maybe you can read the source of qemu.
Actually there are two state in gdb. Which are RUNNING and !RUNNING.

  • The interrupt packet is special. It only need to be handled in RUNNING state. When the interrupt packet is received in RUNNING state, the vm should be stopped and gdb will transfer to !RUNNING state.
  • On the other hand, the normal packet only need to be handled in !RUNNING state. There's no need to handle normal packet in RUNNING state. It doesn't make any sense.

So there's no need to put conn_try_recv_intr to another thread. Just handle the packet in corresponding state in one thread.

@RinHizakura
Copy link
Owner

I'll try to find time to check. Feel free to send the pull request if you have any ideas to fix. Thanks for the review!

@RinHizakura
Copy link
Owner

After some thinking, I am still confused about the comments. The key here is that when the emulator is running in gdbstub->ops->cont(args), there's no way to switch from RUNNING to !RUNNING state for the emulator. In other words, the routine is under the emulator side so gdbstub side can react to the packet with a single thread in this case. I am not sure if registering a signal handler can be a better solution, but we definitely need some mechanism to receive the packet when the emulator is running.

Could you provide a piece of sample to show your idea? Or if possible sending a pull request for this will be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants