lcgamboa / picsimlab

PICsimLab - Programmable IC Simulator Laboratory
GNU General Public License v2.0
441 stars 85 forks source link

Starting QEMU with -S to await a GDB connection #116

Open dcabanis opened 3 days ago

dcabanis commented 3 days ago

Hello all,

I am not sure if this is a bug or more an un-expected behaviour.

When using QEMU for emulation (Blue Pill board), especially in the context of embedded development, you might often need to debug early initialisation code. This is particularly useful in Bare metal (Rust in my case). To start QEMU in a mode where it waits for a GDB connection before starting execution I typically use the -S option. This option makes QEMU not start the execution of the guest until you explicitly give the command in GDB.

When I use the Blue Pill board. The program starts execution as soon as the binary is loaded (even when the Debug mode is enabled).

I might be doing something wrong but I would be expecting the execution of the model to only start when GDB is attached to it. Certainly, this is how its usually done when using QEMU for bare metal development.

Am I miss understanding something?

Kindly,

David.

lcgamboa commented 3 days ago

Hi @dcabanis ,

PICSimLab aims to work as close as possible to the real boards it simulates. In the case of qemu's -S flag, even passing it as an argument, it has no effect because the start of the simulation is a system_reset in qemu. The simplest way to get around this limitation is to do as on real boards, place a breakpoint at the beginning of the code and press the reset button. I don't know your use case, but disabling reset (commenting out this line of code) and adding -S makes the simulator stop waiting for gdb to connect.

Best regards,

Luis Claudio.

dcabanis commented 2 days ago

Thank you Luis,

I have tried the inline assembly bkpt instruction ( asm::bkpt() ). The execution jumps to hardfault immediately. It could just be a limitation of the QEMU model. Keeping in mind that Arm states that the BKPT instruction should not be used in user code since its behaviour is not guarenteed from one core to another. In your message you have mentioned the ability to add a -S argument to the invocation of QEMU. I have to admit I have only used PicSimLab graphically so far. Is there a config file I can use to append this argument? Or is it something I need to alter in the source file along with commenting the system_reset line before recompiling PicSimLab? By the way I am using PicSimLab for a embedded Rust class I am creating. So far I am absolutely amazed by the work you have done (mainly on the Cortex-M based platforms). Thank you so much for this. If you wanted to demonstrate how to use your program in a Rust environment (as an alternative to C/C++) I would be happy to provide you with a small tutorial on the blue pill PicSimLab board.

Thanks again, David.

lcgamboa commented 1 day ago

Hi @dcabanis ,

In PICSimLab, ESP32 qemu-based boards have a configuration window where extra parameters can be passed to qemu. This window has not yet been added for STM32. I will add this support. I did some tests and commenting out the previous line code of what I had informed makes the -S option work. I will let you know when I make these updates. Your examples will be handy for testing (I know, but I haven't used Rust yet).

Best regards, Luis Claudio.

lcgamboa commented 1 day ago

Hi @dcabanis ,

I have added the qemu configuration window to STM32 boards with the option to wait for GDB. You can test on the latest version.

Best regards, Luis Claudio.