Re: GDB breakpoints are broken in new threads -- here's why

[Samuel Thibault]

Hello,

Sergey Bugaev, le dim. 02 avril 2023 15:22:33 +0300, a ecrit:
> I propose the following: before resetting the exception port, glibc
> would fetch the previous one, and if it's non-null, it will perform a
> special synchronous RPC on it, both passing the new exception port
> that it would set to the tracer (so there's no need to actually set
> it), and telling the tracer what its signal thread is (currently GDB
> just tries to guess that the second thread is the one, except this
> again doesn't work for the very same reason, there's not yet a second
> thread when the task is at its very _start).
> 
> routine name_to_be_bikeshedded (
>         tracer_exc_port: mach_port_move_send_t;
>         my_exc_port: mach_port_make_send_t;
>         signal_thread: thread_t);

Yes, that seems much more cooperative.

I would say call it exception_set_exception_port?

> Any ideas how to fix the first issue (thread and subcode info getting
> lost when forwarding signals to the tracer)?

I'd say just add an extended proc_wait RPC indeed. proc can easily
implement both, and new callers can revert to the old version.

Samuel