From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16986 invoked by alias); 7 May 2013 14:49:36 -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 16971 invoked by uid 89); 7 May 2013 14:49:33 -0000 X-Spam-SWARE-Status: No, score=-8.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,TW_EB autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 14:49:33 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r47EnVNo030687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 May 2013 10:49:31 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r47EnUNd001486; Tue, 7 May 2013 10:49:30 -0400 Message-ID: <51891479.70000@redhat.com> Date: Tue, 07 May 2013 14:49:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Mike Frysinger CC: gdb-patches@sourceware.org Subject: Re: [PATCH v2] gdb: clean up x86 cpuid implementations References: <201305061451.24861.vapier@gentoo.org> <51890AC5.2080109@redhat.com> <51890D5A.4080400@redhat.com> <201305071031.12413.vapier@gentoo.org> In-Reply-To: <201305071031.12413.vapier@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00233.txt.bz2 On 05/07/2013 03:31 PM, Mike Frysinger wrote: > On Tuesday 07 May 2013 10:19:06 Pedro Alves wrote: >> On 05/07/2013 03:08 PM, Pedro Alves wrote: >>> On 05/07/2013 02:29 PM, Mike Frysinger wrote: >>>> Fortunately, that last header there is pretty damn good -- it handles >>>> lots of edge cases, the code is nice & tight (uses gcc asm operands >>>> rather than manual movs), and is already almost a general library type >>>> header. >>> >>> The top of the header says: >>> >>> /* Helper file for i386 platform. Runtime check for MMX/SSE/SSE2/AVX >>> * support. Copied from gcc 4.4. >>> >>> I'd rather not fork the gcc file. If we need to wrap its >>> functions/macros for gdb's purpose, I'd rather do that in a separate >>> file that >>> #includes (a copy of) gcc's, verbatim, so we can pull updates from >>> upstream easily. In fact, diffing our copy against gcc's shows we're >>> already out of date --- see below. The bits removed are gdb-specific >>> additions. >>> >>> I wonder whether pushing the file down to libiberty, so both gcc >>> and gdb could share it would be viable? >> >> Actually, it seems like __get_cpuid is a gcc built-in nowadays, but I don't >> when it was added. We could make use of it, and only fallback to the >> header copy if the host compiler doesn't have the builtin. > > yes, gcc introduced a cpuid.h starting with gcc-4.3.0. i wanted to focus on > getting everyone on the same header first before tackling that. Your changes were effectively diverging our header from gcc's, not converging. i didn't think people would be ok with x86 builds requiring gcc-4.3.0 ? Right, and I did not suggest that? The fallback part would take care of < gcc 4.3 (and then at some point in the distant future older gccs would become irrelevant and we drop the fallback). But yes, an autocheck can/could be done separately. Really the main issue is with the forking of gcc's __get_cpuid, like in static __inline int -__get_cpuid (unsigned int __level, - unsigned int *__eax, unsigned int *__ebx, - unsigned int *__ecx, unsigned int *__edx) +i386_cpuid (unsigned int __level, + unsigned int *__eax, unsigned int *__ebx, + unsigned int *__ecx, unsigned int *__edx) { + unsigned int __scratch; unsigned int __ext = __level & 0x80000000; + if (!__eax) + __eax = &__scratch; + if (!__ebx) + __ebx = &__scratch; + if (!__ecx) + __ecx = &__scratch; + if (!__edx) + __edx = &__scratch; + if (__get_cpuid_max (__ext, 0) < __level) - return 0; + return 1; instead of building on it. -- Pedro Alves