From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24245 invoked by alias); 7 May 2013 15:05:03 -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 24229 invoked by uid 89); 7 May 2013 15:05:03 -0000 X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 15:05:02 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A8F3E33BF45; Tue, 7 May 2013 15:05:00 +0000 (UTC) From: Mike Frysinger To: Pedro Alves Subject: Re: [PATCH v2] gdb: clean up x86 cpuid implementations Date: Tue, 07 May 2013 15:05:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.8.3; KDE/4.6.5; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201305061451.24861.vapier@gentoo.org> <201305071031.12413.vapier@gentoo.org> <51891479.70000@redhat.com> In-Reply-To: <51891479.70000@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9656642.kfg8BIdkvL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201305071105.02466.vapier@gentoo.org> X-Virus-Found: No X-SW-Source: 2013-05/txt/msg00235.txt.bz2 --nextPart9656642.kfg8BIdkvL Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 2773 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 ty= pe > >>>> header. > >>>=20 > >>> The top of the header says: > >>>=20 > >>> /* Helper file for i386 platform. Runtime check for MMX/SSE/SSE2/AVX > >>>=20 > >>> * support. Copied from gcc 4.4. > >>>=20 > >>> 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. > >>>=20 > >>> I wonder whether pushing the file down to libiberty, so both gcc > >>> and gdb could share it would be viable? > >>=20 > >> 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. > >=20 > > yes, gcc introduced a cpuid.h starting with gcc-4.3.0. i wanted to foc= us > > on getting everyone on the same header first before tackling that. >=20 > 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=20 provides a simpler interface (usable for all arches, and arguments are=20 optional). what happens internally (include gcc cpuid.h or some copy or=20 whatever) is irrelevant to the external consumers. > > i didn't think people would be ok with x86 builds requiring gcc-4.3.0 ? >=20 > Right, and I did not suggest that? i didn't say you did. i was asking a question to see if we could avoid hav= ing=20 a copy at all. > 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. if we're going to ship a copy of the gcc header, then we might as always ju= st=20 use that instead of switching between the gcc version and the local copy.= =20=20 otherwise we get into the situation where the API used by people works for = the=20 people who do development and often have the latest gcc version and people = who=20 build with older versions. -mike --nextPart9656642.kfg8BIdkvL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJRiRgeAAoJEEFjO5/oN/WBRUIP/1Gd1hFpOiLtL51/xG3oETr7 FnpUtMVr4HRKWfttcrZbaWMW/eQoHiXU2yM16Mbrea9fIqOuxOb3eqNBRmgPxCSQ peSC9DYa8sW8IRWZDJ+eioK7IfnJp+qbFZke1zDQKxDHMC4JeyDHHlfEgHme6Gwu 4jdVS2YUX+JbLbPIs803kGb66pQ35iYpKJYfGnR/bg7HiH9BaIlIOAP9DZ1R3SzF Y0ZthrGb0BiDoIYXR3Qg78+rfGMywnhs4shESWlGo7FpXih1tJau9TSAh7dVswJ+ dQVIEabFoBSYWdPyPatpU8M0eawjuxIaYbhXPaI11aHwCJ7u5OnMrKGQjHahRbk9 1EFxaCnIKfM5ivpno+AkHbubPrQzuyv43GZ0j3QaizfN4PvX2gYmYSw+4m/Ek0Y+ qoLGyyLMeF4A3iw3xGngUkSb1ctIwJPSEdqRBoWXR9toZhGowva9F48MGemozLj4 751rhkPaK+m7E/0ACtTfnUeaWQVz13AkhdZHCmHROOs8mXgqx4fgzsluSs6Vrjyl 5Xee9GvOBr4S7sAYb/XHZ5d8wYrXn1xcV5oaLSVnuVx7VpUagbgqqL4MQGCVSdNx gBsE3H5tfylXJOx7ippWdY0ZM8eCQtla8NSrCt4jkp161Lu8pM97U7o52PN8a0zH qhDnhsWiBF6P/6LOftRK =6qSd -----END PGP SIGNATURE----- --nextPart9656642.kfg8BIdkvL--