From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49080 invoked by alias); 4 May 2018 18:58:24 -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 49066 invoked by uid 89); 4 May 2018 18:58:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1096, risk X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 May 2018 18:58:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 77D2F117C3F; Fri, 4 May 2018 14:58:20 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31Be+FOttyQW; Fri, 4 May 2018 14:58:20 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 47340117BF1; Fri, 4 May 2018 14:58:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 917C983055; Fri, 4 May 2018 11:58:18 -0700 (PDT) Date: Fri, 04 May 2018 18:58:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] gdbserver/Windows: crash during connection establishment phase Message-ID: <20180504185818.htyn2gj2xx5i5s7f@adacore.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8700c375-c37b-9e59-d069-d62b6043b112@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-05/txt/msg00139.txt.bz2 > > +#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. -- Joel PS: If you are surprised by me saying I can't test on LynxOS at the moment, it's because I don't have a C++ cross compiler for that platform. I'm still hoping that we might be able to build one, but it requires some work.