From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82430 invoked by alias); 31 Mar 2015 16:30:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 82419 invoked by uid 89); 31 Mar 2015 16:30:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 31 Mar 2015 16:30:25 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2VGUO19032647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 31 Mar 2015 12:30:24 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2VGUMVT026340 for ; Tue, 31 Mar 2015 12:30:23 -0400 Message-ID: <551ACB9E.2080902@redhat.com> Date: Tue, 31 Mar 2015 16:30:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [patch/cygwin] Remove dependency on __COPY_CONTEXT_SIZE References: <20150330100454.GA8372@calimero.vinschen.de> <551A9443.5010907@redhat.com> <20150331143643.GA10846@calimero.vinschen.de> <551AB630.4010800@redhat.com> <20150331154215.GL13285@calimero.vinschen.de> In-Reply-To: <20150331154215.GL13285@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg01056.txt.bz2 On 03/31/2015 04:42 PM, Corinna Vinschen wrote: > On Mar 31 15:58, Pedro Alves wrote: >> On 03/31/2015 03:36 PM, Corinna Vinschen wrote: >>> On Mar 31 13:34, Pedro Alves wrote: >>>> On 03/30/2015 11:04 AM, Corinna Vinschen wrote: >>>> >>>>> @@ -820,7 +819,7 @@ handle_output_debug_string (struct target_waitstatus *ourstatus) >>>>> #endif >>>>> warning (("%s"), s); >>>>> } >>>>> -#ifdef __COPY_CONTEXT_SIZE >>>>> +#ifdef __CYGWIN__ >>>>> else >>>>> { >>>>> /* Got a cygwin signal marker. A cygwin signal is followed by >>>>> @@ -847,8 +846,8 @@ handle_output_debug_string (struct target_waitstatus *ourstatus) >>>>> else if ((x = (LPCVOID) (uintptr_t) strtoull (p, NULL, 0)) >>>>> && ReadProcessMemory (current_process_handle, x, >>>>> &saved_context, >>>>> - __COPY_CONTEXT_SIZE, &n) >>>>> - && n == __COPY_CONTEXT_SIZE) >>>>> + sizeof (CONTEXT), &n) >>>> >>>> Is that really wise? AFAIK, the size of the CONTEXT structure can >>>> grow as MSFT adds more registers to support newer machines. >>> >>> No, that's not possible. The CONTEXT structure matches the platform. >>> It doesn't even contain a version number. Consider that the structure >>> is available in user space. If Microsoft changes the size on a given >>> platform, applications built for this platform might crash due to >>> overwritten memory. They wouldn't do that. >> >> That's not true. GetThreadContext takes a size parameter, >> and only writes to the bits that the caller requests with >> context.ContextFlags. > > The ContextFlags member is not a size parameter, I didn't say it was. The GetThreadContext function takes an IN+OUT size parameter in _addition to the ContextFlags flag. Both can be used for versioning. >> See the description of InitializeContext's parameters: >> >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh134237%28v=vs.85%29.aspx >> >> And the remarks section: >> >> "InitializeContext can be used to initialize a CONTEXT structure within a buffer >> with the required size and alignment characteristics. This routine is required if >> the CONTEXT_XSTATE ContextFlag is specified since the required context >> size and alignment may change depending on which processor features are >> enabled on the system. > > Right, but this does not change the size of the CONTEXT datatype. The > additional AVX values require more space than available in the CONTEXT > struct. That's why using CONTEXT_XSTATE and the AVX functions require > to use InitializeContext; the size required to get these values is > larger than CONTEXT, thus the function returns ERROR_INSUFFICIENT_BUFFER > if ContextLength is == sizeof (CONTEXT) only. I'm almost sure in the old days, the CONTEXT structure didn't have the ExtendedRegisters field at all. I think it's bad to hard code the size of the CONTEXT structure, but won't argue further. Patch is OK if you'd really like to apply it as is. @@ -847,8 +846,8 @@ handle_output_debug_string (struct target_waitstatus *ourstatus) else if ((x = (LPCVOID) (uintptr_t) strtoull (p, NULL, 0)) && ReadProcessMemory (current_process_handle, x, &saved_context, - __COPY_CONTEXT_SIZE, &n) - && n == __COPY_CONTEXT_SIZE) + sizeof (CONTEXT), &n) + && n == sizeof (CONTEXT)) have_saved_context = 1; current_event.dwThreadId = retval; } > > And, we're not using this. The local variable filled with the data is > of type CONTEXT and the data transmitted from Cygwin to GDB is of type > CONTEXT. It's still the same size, independent of the availablity of > CONTEXT_XSTATE. Where can the debugger find the signal's xstate state then? Thanks, Pedro Alves