[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Samuel Thibault
Subject: Re: GDB breakpoints are broken in new threads -- here's why
Date: Tue, 11 Apr 2023 00:50:45 +0200
User-agent: NeoMutt/20170609 (1.8.3)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]