On Wed, Apr 5, 2023 at 5:37 AM Evgeniy Naydanov < evgeniy.nayda...@syntacore.com> wrote:
> Thank you for your answers! > > If I understood correctly the intended behavior is for all harts to resume > at the specified address. However, maybe you could clarify on the second > part of my original question: > What should be done if some targets have already been resumed (e.g., > selected hart has been stopped because of a software breakpoint, but others > in the SMP group continue to run)? Should an error be reported, or should > non-halted hart be 'resumed' at the specified address? > I think it depends mostly on how effectively we can communicate to the user what is going on, and what options the user has when they encounter the error. gdb is pretty limited in the kinds of things it understands and accepts. Ideally, if the user requests all harts to resume at a certain address, and some are already running, the user gets an error explaining that some harts are running so the request can't be done. Then they should have the option to resume only the halted harts from the given address (ignore the error). Maybe ignoring that particular error should be a flag to the original command. If we can't make that happen, then we'll have to implement what the user "usually" wants. I think that is to report a warning and only change the PC on those harts that are halted. If the user sees the warning they can halt everything and do the resume again. If we fail instead, then there is no good way for the user to only set the PC on the halted harts and resume them. Tim > Example (core0.cpu and core1.cpu are in SMP group): > reset halt > targets core0.cpu > bp <some address> > resume > //core0.cpu hits software breakpoint and halts, so core0.cpu is halted, > but core1.cpu is still running > resume <some other address> > //Any idea what should happen here? > > 29.03.2023, 01:19, "Tommy Murphy" <tommy_mur...@hotmail.com>: > > > As for address, I don't see that it would ever make sense for all cores > to resume at the same address. > > There are cases where it could make sense. E.g. common startup code > executed by all cores (aka RISC-V harts). In fact, a lot of multi-hart > RISC-V implementions do exactly that at startup - have all harts execute > some common/shared code until such time as initialisation gets them > executing different code from different memory regions. > > > So if the resume address is specified in a multi-core configuration, > then either: > > > 1) only that core should resume, or > > What do you mean by "that core"? > > Aren't all cores treated as a single entity when part of an SMP group, in > particular when it comes to halt and resume? The OpenOCD resume command has > no way of identifying an individual SMP core and I don't know of any "out > of band" mechanism for doing so either? > > If an (optional) address is specified to the resume command then, as > things stand, it seems correct to me from an OpenOCD perspective for all > cores to be resumed at that address. Whether or not that makes sense is the > responsibility of the debugger user. :-) > , > >
