Re: Program-assigned thread names on Windows

[LRN <lrn1986 at gmail dot com>]

On 26.07.2016 18:40, LRN wrote:
> 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.
> 

Attached is the last (hopefully) iteration of the patch.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org

Attachment: 0001-Support-settings-thread-name-MS-Windows.patch
Description: Text document

Attachment: 0x6759BA74.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature