From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65603 invoked by alias); 4 May 2018 19:12:22 -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 65582 invoked by uid 89); 4 May 2018 19:12:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 May 2018 19:12:20 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3F0548D777; Fri, 4 May 2018 19:12:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id BEFD2111E3F1; Fri, 4 May 2018 19:12:18 +0000 (UTC) Subject: Re: [PATCH 3/3] gdbserver/Windows: crash during connection establishment phase To: Joel Brobecker References: <1525458603-33351-1-git-send-email-brobecker@adacore.com> <1525458603-33351-4-git-send-email-brobecker@adacore.com> <8700c375-c37b-9e59-d069-d62b6043b112@redhat.com> <20180504185818.htyn2gj2xx5i5s7f@adacore.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <03cdded5-9f4e-fc1a-366a-1be7cd8b1837@redhat.com> Date: Fri, 04 May 2018 19:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180504185818.htyn2gj2xx5i5s7f@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00141.txt.bz2 On 05/04/2018 07:58 PM, Joel Brobecker wrote: >>> +#ifndef IN_PROCESS_AGENT >>> +#ifdef __x86_64__ >>> + static const char *expedite_regs_amd64[] = { "rbp", "rsp", "rip", NULL }; >>> + tdesc->expedite_regs = expedite_regs_amd64; >>> +#else /* __x86_64__ */ >>> + static const char *expedite_regs_i386[] = { "ebp", "esp", "eip", NULL }; >>> + tdesc->expedite_regs = expedite_regs_i386; >>> +#endif /* __x86_64__ */ >>> +#endif >> >> Won't all x86 ports have the same problem? I.e., don't >> nto-x86-low.c:nto_x86_arch_setup and >> lynx-i386-low.c:lynx_i386_arch_setup need the same treatment? >> Should we put those arrays in some shared i386 file? > > They probably would, but these are platforms I cannot test at > the moment, so I didn't want to take a risk and create a situation > for them. I'm quite happy to adjust the way you suggest. I think I'd take the risk anyway, even without testing. (Just like the original patch that broke them didn't get testing on !Linux ports.) They're already most probably broken, so we can't be making it worse, IMO. Thanks, Pedro Alves