Program-assigned thread names on Windows

[LRN]

On 26.07.2016 17:17, LRN wrote:
> On 26.07.2016 16:18, Jon Turney wrote:
>> On 26/07/2016 07:07, LRN wrote:
>>> On 26.07.2016 0:32, LRN wrote:
>>>>> On 25.07.2016 17:23, LRN wrote:
>>>>>>> On 25.07.2016 17:06, Jon Turney wrote:
>>>>>>>>> On 25/07/2016 14:34, LRN wrote:
>>>>>>>>>>> On 25.07.2016 15:17, Jon Turney wrote:
>>>>>>>>>>>>> On 23/07/2016 18:01, LRN wrote:
>>>>> seem to point to the stack, but that's all i can tell). Also, the 4-th
>>>>> element (which is "Reserved for future use, must be zero") is not zero when
>>>>> the exception is caught.
>>>>> In light of this, we should probably check for NumberParameters >= 4. Or
>>>>> even NumberParameters >= 3, given that we don't really look at the 4th
>>>>> parameter.
>>
>> It seems on x86_64, the structure is laid out by gcc as:
>>
>> 4 DWORD dwType
>> 4 padding
>> 8 LPCSTR szName
>> 4 DWORD dwThreadID
>> 4 DWORD dwFlags
>>
>> total size 24, so nNumberOfArguments = 3, so this is passed to the 
>> debugger as an array of 3 DWORD64s
>>
>> Of course, the 'correct' layout is defined by how the sample code is 
>> laid out by MSVC, which I'm guessing is the same, but haven't checked...
>>
>> So dwThreadID and dwFlags get packed together into 
>> ExceptionInformation[2].  Fortunately, dwFlags should be set to 0.
>>
>> Furthermore, accessing dwType as a DWORD64 value via 
>> ExceptionInformation[0] relies on the padding being zero initialized in 
>> the debugee to have useful values! I guess you'll have to mask with 0xffff?
> 
> I'll play a bit with the 64-bit exception-throwing example and see how
> WinDbg reacts to various combinations of alignment and argument counting,
> and will make gdb support the layout that WinDbg supports.

Played around with 64-bit WinDbg.
It worked with the code that i've used originally (from MSDN with no
significant changes). Also:

1) WinDbg (of either bitness) doesn't care what the argument count is, as
long as it's at least 3 (0x1000, string pointer and thread ID); giving it 2
makes it silently drop the exception and not set the thread name

2) WinDbg (of either bitness) currently doesn't care what you put in
dwFlags. I've tried filling dwFlags with garbage (a copy of the dwThreadID
value, for example), and WinDbg still set the thread name correctly,
without misidentifying the thread.
This leads me to believe that, as you've suggested, 64-bit WinDbg does &
0x00000000FFFFFFFF on ExceptionInformation[2] (32-bit WinDbg doesn't have to).

Also of note, 32-bit WinDbg can't debug 64-bit executables, but 64-bit
WinDbg can debug 32-bit executables.

Maybe they foresaw the use of 64-bit architectures (i can't dig deeper into
the MSDN than MSVC 2003, not sure how the thread-name example looked in
MSVC 6.0 era) and padded the struct size to be a multiple of 8, reserving
the last DWORD for future use; later realized that due to struct packing a
64-bit debugger would get 3 64-bit pointer-sized values, with the last one
being a combination of threadid and flags, and adapted their debugger to
handle exactly this case.

Anyway, for gdb:
1) Look for at least 3 arguments.
2) In 64-bit gdb do the & 0xFFFFFFFF on the 3rd member to get thread id.

And that's it.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x6759BA74.asc
Type: application/pgp-keys
Size: 3482 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20160726/dd97e0d7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20160726/dd97e0d7/attachment.sig>