From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19805 invoked by alias); 6 May 2013 19:44:29 -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 19795 invoked by uid 89); 6 May 2013 19:44:29 -0000 X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL autolearn=no version=3.3.1 Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 06 May 2013 19:44:27 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MME00F006RQYC00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Mon, 06 May 2013 22:44:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MME00FP56TVNN80@a-mtaout21.012.net.il>; Mon, 06 May 2013 22:44:20 +0300 (IDT) Date: Mon, 06 May 2013 19:44:00 -0000 From: Eli Zaretskii Subject: Re: [patch/rfc] gdb: clean up x86 cpuid implementations In-reply-to: <201305061451.24861.vapier@gentoo.org> To: Mike Frysinger Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <831u9jgagk.fsf@gnu.org> References: <201305061451.24861.vapier@gentoo.org> X-SW-Source: 2013-05/txt/msg00147.txt.bz2 > From: Mike Frysinger > Date: Mon, 6 May 2013 14:51:24 -0400 > > We've currently got 3 files doing open coded implementations of cpuid. > Each has its own set of workarounds and varying levels of how well > they're written and are generally hardcoded to specific cpuid functions. > If you try to build the latest gdb as a PIE on an i386 system, the build > will fail because one of them lacks PIC workarounds (wrt ebx). Sorry, I don't follow: what workarounds, and why are they needed? And what's PIE got to do with the go32 target? The current code in go32-nat.c was tested to work in all the environments supported by that target, without GPFaulting or triggering any other disasters. I don't think we have the resources to repeat all that testing with the new code, which tries to detect newer CPUs, and so could trigger SIGILL. So I'd like to leave go32-nat.c alone, if possible.