RE: multiprocess+ target remote and resume after breakpoint hit

On Friday, March 7, 2025 2:58 PM, Matthias Pfaller wrote:
> Interrupting and continuing threads  is working fine. But when I set a break point
> and the thread is interrupted, gdb will still stop all threads. It will then disable
> the break point, step over the break point and reanable the break point. After this
> is done it will continue all threads. But my system will of course die when all
> threads are stopped... I would need gdb to stop only the threads associated with the
> break point.

In non-stop mode GDB needs to pause all threads behind the curtain to make the eventing
thread step over the breakpoint.  Otherwise, while the breakpoint is momentarily disabled,
other threads may omit hitting it.  There is the displaced stepping concept to keep the
other threads still running.  Have you looked at it?

> Is there a way for the target to communicate to gdb that every thread is using the
> same executable?

Did you mean every *process*?  There is the exec-file property that GDB queries after
attaching or after a new inferior is noticed.  You say you model each thread separately
as a process.  Do you make GDB connect to your remote target via 'target extended-remote'
and then use the 'attach' command?  If during attach the server reports multiple processes
to GDB (e.g. in update_thread_list), things may go somewhat out-of-sync, and I presume
the 'exec-file' query would not work for you properly if that's the case.

Regards
-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928