From: Jon Turney <jon.turney@dronecode.org.uk>
To: gdb-patches@sourceware.org
Cc: LRN <lrn1986@gmail.com>
Subject: Re: Program-assigned thread names on Windows
Date: Mon, 25 Jul 2016 12:17:00 -0000 [thread overview]
Message-ID: <adcfdf1d-26df-1eb0-2730-16d51193e575@dronecode.org.uk> (raw)
In-Reply-To: <6a3446f9-63dc-67a1-3702-203d77c8d85d@gmail.com>
On 23/07/2016 18:01, LRN wrote:
> On 23.07.2016 19:39, John Baldwin wrote:
>> > On Saturday, July 23, 2016 12:25:15 PM LRN wrote:
>>> >> The attached patch adds thread naming support on Windows.
Nice. A few comments below.
>>> >>
>>> >> This works as documented[1] on MSDN - by catching a specific
>>> >> exception that the program throws.
>>> >>
>>> >> Setting thread name this way is supported by glib[2] and winpthreads[3]
>>> >> at least, as well as any program developed with MS toolchain (because
>>> >> WinDbg supported this for a long time).
>>> >>
>>> >> [1] https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
>>> >> [2] https://git.gnome.org/browse/glib/commit/glib
>>> >> /gthread-win32.c?id=e118856430a798bbc529691ad235fd0b0684439d
>>> >> [3] https://sourceforge.net/p/mingw-w64/mingw-w64/ci
>>> >> /0d95c795b44b76e1b60dfc119fd93cfd0cb35816/
>> >
>
> This is done by catching an exception number 0x406D1388
> (it has no documented name), which is thrown by the program.
The name used in the MSDN article [1] is 'MS_VC_EXCEPTION', so why not
use that?
> + case WINDOWS_THREADNAME_EXCEPTION:
> + DEBUG_EXCEPTION_SIMPLE (WINDOWS_THREADNAME_EXCEPTION_S);
> + ourstatus->value.sig = GDB_SIGNAL_TRAP;
> + if (current_event.u.Exception.ExceptionRecord.NumberParameters == 4)
> + {
> + DWORD named_thread_id;
> + ptid_t named_thread_ptid;
> + struct thread_info *named_thread;
> + uintptr_t thread_name_target;
> + char *thread_name;
> +
Shouldn't this check for ExceptionInformation[0] = 0x1000, and treat
this as an unknown exception otherwise?
> + named_thread_id = (DWORD) current_event.u.Exception.ExceptionRecord.ExceptionInformation[2];
> + thread_name_target = (uintptr_t) current_event.u.Exception.ExceptionRecord.ExceptionInformation[1];
Is this going to be correct for 64-bit builds?
> +
> + if (named_thread_id == (DWORD) -1)
> + named_thread_id = current_event.dwThreadId;
> +
> + named_thread_ptid = ptid_build (current_event.dwProcessId, 0, named_thread_id),
> + named_thread = find_thread_ptid (named_thread_ptid);
> +
> + thread_name = NULL;
> + if (target_read_string ((CORE_ADDR) thread_name_target, &thread_name, 1024, 0))
Does thread_name end up not being null terminated if the thread name
length really exceeds 1024? (or is improperly not null terminated in the
target process...)
> + {
> + if (thread_name != NULL && thread_name[0] != '\0')
> + {
> + xfree (named_thread->name);
> + named_thread->name = thread_name;
> + }
> + else if (thread_name != NULL)
> + {
> + /* nothing to do */;
> + xfree (thread_name);
> + }
> + }
> + result = 2;
> + }
> + break;
> default:
> /* Treat unhandled first chance exceptions specially. */
> if (current_event.u.Exception.dwFirstChance)
> @@ -1153,7 +1194,7 @@ handle_exception (struct target_waitstatus *ourstatus)
> }
> exception_count++;
> last_sig = ourstatus->value.sig;
> - return 1;
> + return result;
> }
>
> /* Resume thread specified by ID, or all artificially suspended
> @@ -1510,10 +1551,19 @@ get_windows_debug_event (struct target_ops *ops,
> "EXCEPTION_DEBUG_EVENT"));
> if (saw_create != 1)
> break;
> - if (handle_exception (ourstatus))
> - thread_id = current_event.dwThreadId;
> - else
> - continue_status = DBG_EXCEPTION_NOT_HANDLED;
> + switch (handle_exception (ourstatus))
> + {
> + case 0:
> + default:
> + continue_status = DBG_EXCEPTION_NOT_HANDLED;
> + break;
> + case 1:
> + thread_id = current_event.dwThreadId;
> + break;
> + case 2:
> + continue_status = DBG_CONTINUE;
> + break;
> + }
> break;
>
> case OUTPUT_DEBUG_STRING_EVENT: /* Message from the kernel. */
> -- 2.4.0
>
next prev parent reply other threads:[~2016-07-25 12:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-23 9:25 LRN
2016-07-23 9:33 ` Eli Zaretskii
2016-07-23 9:43 ` LRN
2016-07-23 10:18 ` Eli Zaretskii
2016-07-23 16:43 ` John Baldwin
2016-07-23 17:01 ` LRN
2016-07-25 12:17 ` Jon Turney [this message]
2016-07-25 13:34 ` LRN
2016-07-25 14:07 ` Jon Turney
[not found] ` <e50e62e8-b3a8-cd4a-aff0-ea2097cf2412@gmail.com>
2016-07-25 21:33 ` LRN
2016-07-26 6:08 ` LRN
2016-07-26 13:18 ` Jon Turney
2016-07-26 14:17 ` LRN
2016-07-26 15:41 ` LRN
2016-07-26 17:15 ` LRN
2016-07-26 22:20 ` Jon Turney
2016-07-27 21:35 ` Jon Turney
2016-07-28 7:21 ` LRN
2016-08-02 9:47 ` LRN
2016-08-02 14:55 ` Eli Zaretskii
2016-08-10 7:12 ` LRN
2016-08-10 12:15 ` Pedro Alves
2016-08-10 17:54 ` LRN
2016-08-10 18:45 ` Pedro Alves
2016-08-10 23:42 ` LRN
2016-08-11 0:39 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adcfdf1d-26df-1eb0-2730-16d51193e575@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=gdb-patches@sourceware.org \
--cc=lrn1986@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).