gdbstub debug of multi-cluster machines is undocumented and confusing

Bug #1921092 reported by Martin Schönstedt
2
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

Working with Zephyr RTOS, running a multi core sample on mps2_an521 works fine. Both cpus start.
Trying to debug with options -s -S the second core fails to boot.

Posted with explanation also at: https://github.com/zephyrproject-rtos/zephyr/issues/33635

Tags: arm debug
description: updated
description: updated
Revision history for this message
Martin Schönstedt (m-schoenstedt) wrote : Re: how do i delete this bug?

there was no bug, it was my fault. How do I delete this

Changed in qemu:
status: New → Invalid
summary: - qemu-system-arm multi core debug not working
+ how do i delete this bug?
description: updated
Revision history for this message
Peter Maydell (pmaydell) wrote :

In general, you don't need to delete bugs that turn out to be user error, or edit the description/title; just mark them as 'invalid', perhaps with a comment about what turned out to be the cause. That leaves the trail of what was going on for future readers who might be going down the same path as you.

There are actually a couple of things we should do here in upstream QEMU:

* we should document the process for using the debugstub with multi-cluster board models like the mps2-an521
* we should check whether we are doing the right/most appropriate thing when the user connects to the debug stub and is only attaching to one 'inferior' -- it sounds from your report like the un-attached inferior is left permanently in the 'stopped' state. Maybe that's what the gdb protocol requires, but it seems a bit unhelpful.

I'm going to update the bug status/text accordingly.

summary: - how do i delete this bug?
+ gdbstub debug of multi-cluster machines is undocumented and confusing
Changed in qemu:
status: Invalid → Confirmed
description: updated
Revision history for this message
Martin Schönstedt (m-schoenstedt) wrote :

Thanks for the answer,

indeed the second cluster of the board has been halted when I was starting gdb the "normal" way - not adding the second inferior. In my own research I did not find out about these inferiors, so I was wondering why "info threads" did only show one cpu. Maybe gdb could inform the user about unattached inferiors when using "info threads"

Revision history for this message
Peter Maydell (pmaydell) wrote :

Could you provide an example QEMU command line and guest image file which you were having this problem with, please? That would save me figuring out how to build zephyr binaries :-)

Revision history for this message
Martin Schönstedt (m-schoenstedt) wrote :

qemu-system-arm -cpu cortex-m33 -machine mps2-an521 -nographic -m 16 -vga none -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -icount shift=7,align=off,sleep=off -rtc clock=vm -device loader,file=<remote_dir>/zephyr.elf -s -S -kernel <master_dir>/zephyr.elf

i've included both .elf files in a zip. That should be enough for running the sample

Revision history for this message
Peter Maydell (pmaydell) wrote :

There's now a new docs section on debugging multicore (including multi-cluster) machines:

https://qemu-project.gitlab.io/qemu/system/gdb.html#debugging-multicore-machines

Revision history for this message
Thomas Huth (th-huth) wrote :

Is there still anything to do here or could we close the ticket now?

Changed in qemu:
status: Confirmed → Incomplete
Revision history for this message
Martin Schönstedt (m-schoenstedt) wrote :

It can be closed. The added documentation is very helpful.

Revision history for this message
Thomas Huth (th-huth) wrote :

Ok, thanks, so I'm closing this ticket now.

Changed in qemu:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.