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 changed:
- how do i delete this bug?
+ gdbstub debug of multi-cluster machines is undocumented and confusing
** Changed in: qemu
Status: Invalid => Confirmed
** Description changed:
- no bugs here
+ 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
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1921092
Title:
gdbstub debug of multi-cluster machines is undocumented and confusing
Status in QEMU:
Confirmed
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1921092/+subscriptions
