[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) |
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