Re: [PATCH v2 37/47] Windows GDB: make windows_thread_info be private thread_info data

Tom Tromey
2025-05-28T19:53:39Z

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

Pedro> When that is supported, and the core wants to be notified of thread
Pedro> exit events, the target backend does not delete the thread for which
Pedro> the event is being reported. Instead, infrun takes care of that.

I did not know about this detail ... is this documented somewhere?

Pedro> Fix this by eliminating the parallel thread list from the Windows
Pedro> backend, instead making the windows_thread_info data by registered as
Pedro> the private data associated with thread_info, like other targets do.

Nice, thank you.

I was a little worried about possible conflicts with this field, but
searching shows it's either used by the thread layer (aix and linux) or
by the -nat layer (darwin and remote). So it's reasonably robust I guess.

Pedro> +/* Get the windows_thread_info object associated with THR. */
Pedro> +
Pedro> +static windows_thread_info *
Pedro> +as_windows_thread_info (thread_info *thr)
Pedro> +{
Pedro> + /* Cast to windows_private_thread_info, which inherits from
Pedro> + private_thread_info, and is implicitly convertible to
Pedro> + windows_thread_info, the return type. */
Pedro> + return static_cast<windows_private_thread_info *> (thr->priv.get ());

Should this use checked_static_cast instead?

Pedro> +/* Creates an iterator that works like all_matching_threads_iterator,
Pedro> + but that returns windows_thread_info pointers instead of
Pedro> + thread_info. This could be replaced with a std::range::transform
Pedro> + when we require C++20. */

I was going to suggest a note in the meta bug but I see there's already
a note about using the range library.

Tom