search

adamgreen / mri

MRI - Monitor for Remote Inspection. The gdb compatible debug monitor for Cortex-M devices.
Apache License 2.0
155 stars 58 forks source link

FlagSemihostCallAsHandled skip all action if Semihost_IsDebuggeeMakingSemihostCall return false #31

Closed xiaoxiang781216 closed 1 year ago

xiaoxiang781216 commented 2 years ago

@adamgreen I reopen https://github.com/adamgreen/mri/pull/21 again, because it's relate to how to implement the non-block input from gdb console: https://github.com/adamgreen/mri/issues/26.

If we can invoke semihost operation directly in the thread context, and combine with thread mri(https://github.com/adamgreen/mri/issues/27), it's possible to only block the caller thread(shell) instead the whole device.

Of course, we need add code to protect mri core to avoid the multiple thread access the shared resource concurrently.

Do you think so?

adamgreen commented 2 years ago

I don't plan to merge this PR at this time. I still think it is a bad idea but if it somehow can be proven to solve a real problem I will reconsider.

xiaoxiang781216 commented 2 years ago

Sure, but anyway it isn't bad to check whether semihost come from trap instruction again regardless whether the caller go through or bypass the trap instruction.

adamgreen commented 2 years ago

Sure, but anyway it isn't bad to check whether semihost come from trap instruction again regardless whether the caller go through or bypass the trap instruction.

But by design it should only be called from a semi-host trap instruction handler and a bunch of other things are going to break if someone calls it directly as we already discussed, not just this part of the code.

I don't think having a thread pending a "Fread" request to GDB while the other threads are running is likely to work but you should give it a try and see how it works out.

From section E.13.1 File I/O Overview:

The communication is synchronous. A system call is possible only when gdb is waiting for a response from the ‘C’, ‘c’, ‘S’ or ‘s’ packets. While gdb handles the request for a system call, the target is stopped to allow deterministic access to the target’s memory. Therefore File-I/O is not interruptible by target signals. On the other hand, it is possible to interrupt File-I/O by a user interrupt (‘Ctrl-C’) within gdb.

This would seem to indicate that hitting a breakpoint, watchpoint, or single step while there was a pending File I/O would not cause GDB to interrupt that I/O operation from such a "target signal".