This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |