From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11006 invoked by alias); 7 May 2013 02:41:49 -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 10964 invoked by uid 89); 7 May 2013 02:41:49 -0000 X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_NIX_SPAM,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; Tue, 07 May 2013 02:41:46 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MME00H00Q1MSV00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Tue, 07 May 2013 05:41:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MME00H35Q5JRF30@a-mtaout21.012.net.il>; Tue, 07 May 2013 05:41:44 +0300 (IDT) Date: Tue, 07 May 2013 02:41:00 -0000 From: Eli Zaretskii Subject: Re: [patch/rfc] gdb: clean up x86 cpuid implementations In-reply-to: <201305061630.27822.vapier@gentoo.org> To: Mike Frysinger Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83vc6veckf.fsf@gnu.org> References: <201305061451.24861.vapier@gentoo.org> <831u9jgagk.fsf@gnu.org> <201305061630.27822.vapier@gentoo.org> X-SW-Source: 2013-05/txt/msg00164.txt.bz2 > From: Mike Frysinger > Date: Mon, 6 May 2013 16:30:26 -0400 > Cc: gdb-patches@sourceware.org > > > 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. > > on the flip side, if the new common header was tested, go32-nat (and any other > DOS like target) wouldn't have to do anymore work, and would be easy to use > cpuid in more places. That's in theory. In practice, go32 (a.k.a. DJGPP) needs a DPMI server to be able to run 32-bit protected-mode code on top of a 16-bit real-mode OS. The DPMI environment has its own peculiar rules about what can and cannot be done, and more importantly, different DPMI providers bend those rules in different directions. The net result is that not everything that works for any other 386 out there will necessarily work in the DPMI environment. > but in the end, i don't care about dead things like DOS, so if people prefer > to leave the cruft in that one file, i can look the other way while still > cleaning up everything else. Yes, please. Thanks.