On Wed, May 20, 2026 at 10:25 AM Zane Leung <[email protected]> wrote: > > Hi, Antonio > > On 5/20/2026 3:47 PM, Antonio Borneo wrote: > > Hi Zane, > > > > I don't have a target with so many cores in SMP, but I can easily > > replicate the error messages with a single core target by adding a > > delay in the event gdb-attach : > > openocd -f board/stm32mp13x_dk.cfg -c 'stm32mp13x.cpu configure -event > > gdb-attach { sleep 5000; halt }' > > > > The issue is caused by GDB that has a 2 seconds timeout to complete > > the connection with the remote GDB server (OpenOCD for us). > > With the delay in the event or with the latency to halt 80 cores, the > > timeout expires. > > I can workaround it by adding the GDB command > > set remotetimeout 10 > > before the connection command > > target extended-remote :3333 > > Please check and let us know if such a workaround works for you too. > > Thanks for the suggestion, I can workaround it by adding the GDB command > set remotetimeout 10. However, debugging performance is now severely > degraded.I suspect this is due to OpenOCD's periodic polling of target state, > which becomes a bottleneck with large core counts.
I can imagine that polling 80 cores takes time, eventually using all the time available just doing that. OpenOCD doesn't have a command to change the polling interval; it it hardcoded in file src/target/target.h in ms units #define TARGET_DEFAULT_POLLING_INTERVAL 100u The polling is there only to understand if the target state is changed from running to halt. If you change it 1000 ms or more you would probably get better debugging performance. If this really works, adding a new command e.g. 'poll interval' could be a nice improvement. You also have the commands 'poll on' and 'poll off' to temporarily disable the polling. Another improvement, but much more invasive, would be to rewrite the target polling to try to be faster, or even to allow commands between the polling of two cores. I think that today's code preempts the user interaction (GDB included) to poll all the cores in one shot, then giving back the control. On tens of cores this is not going to scale nicely. > > Few years ago I made a patch to send keep-alive to GDB during the > > attach phase, explicitly for this situation, but I cannot find it > > anymore in gerrit. > > My use case was a target that can only be halted in non-secure, so > > OpenOCD has to wait for the firmware to jump from secure to non-secure > > execution before halting it and alerting GDB. > > I will continue looking for it and eventually rebasing it on current code. > > I expect it would fix your issue too, and I would be glad to get you > > confirmation. > Thank you for working on this. I'm glad to provide confirmation once it's > ready. Thanks, and also thanks to Paul for the link. It's that, to be rebased. Antonio
