Re: [RFA] Thread exit messages on MS-Windows

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 29 Apr 2013 14:21:00 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > No one replied, so I'm now converting this into an RFA.  The patch
> > below causes GDB on Windows to display thread exit messages like this:
> > 
> >   [Thread 5920.0x13e4 exited with code 0]
> >   [Thread 5920.0x12d0 exited with code 0]
> >   [Thread 5920.0x1cbc exited with code 0]
> 
> > 2013-04-27  Eli Zaretskii  <eliz@gnu.org>
> > 
> > 	* windows-nat.c (windows_delete_thread): Accept an additional
> > 	argument, the thread's exit code, and announce thread death when
> > 	print_thread_events is non-zero and we are deleting a thread that
> > 	is not the main thread.
> > 	(get_windows_debug_event): Pass thread exit code to
> > 	windows_delete_thread.
> 
> Looks good to me, modulo the comments already made.

I know what to do with Corinna's comment, but not what to decide about
announcing the death of the main thread.  Do you have an opinion?

> It's a little unusual to see an exit code for a thread, but it could
> be useful information, and it does not unnecessarily clutter the
> output.

My reading of the code is that you already see that in linux-native
debugging, see linux-nat.c.

> > @@ -1513,7 +1517,7 @@ get_windows_debug_event (struct target_o
> >        current_process_handle = current_event.u.CreateProcessInfo.hProcess;
> >        if (main_thread_id)
> >  	windows_delete_thread (ptid_build (current_event.dwProcessId, 0,
> > -					   main_thread_id));
> > +					   main_thread_id), 0);
> 
> One tiny nitpick, very possibly influenced by personal preferences,
> so feel free to ignore...  I think that the code would be faster
> to read if the added parameter was moved to the next line. That way,
> all parameters in call to windows_delete_thread would have the same
> indentation level.

I'm surprised, but I don't mind, and will do that, too.