From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12285 invoked by alias); 7 May 2013 15:21:51 -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 12274 invoked by uid 89); 7 May 2013 15:21:51 -0000 X-Spam-SWARE-Status: No, score=-8.4 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 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 15:21:50 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r47FLmW4015537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 May 2013 11:21:48 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r47FLlT1018179; Tue, 7 May 2013 11:21:47 -0400 Message-ID: <51891C0A.9010501@redhat.com> Date: Tue, 07 May 2013 15:21: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> <201305071031.12413.vapier@gentoo.org> <51891479.70000@redhat.com> <201305071105.02466.vapier@gentoo.org> In-Reply-To: <201305071105.02466.vapier@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00237.txt.bz2 On 05/07/2013 04:05 PM, Mike Frysinger wrote: > On Tuesday 07 May 2013 10:49:29 Pedro Alves wrote: >> 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. > > the header provides a simple API that sits between the gcc cpuid.h and gdb and > provides a simpler interface (usable for all arches, and arguments are > optional). Yes, and I'm pointing out that the header is 99% a _modified_ copy of gcc's cpuid.h, which makes updating the file from upstream harder than necessary. Do the simpler interface in a separate file, that consumes gcc's interface, is all I'm saying. > what happens internally (include gcc cpuid.h or some copy or > whatever) is irrelevant to the external consumers. Of course. That's really a straw man, given my point is about simplifying maintenance of the API's internals, not the API itself. >>> i didn't think people would be ok with x86 builds requiring gcc-4.3.0 ? >> >> Right, and I did not suggest that? > > i didn't say you did. i was asking a question to see if we could avoid having > a copy at all. Maybe that's because I'm not a native speaker, but "would people be ok?" would a variant of that question that didn't sound like implying I had said it, to me. -- Pedro Alves