This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Sriraman Tallam <tmsriram at google dot com>
- Cc: reply at codereview dot appspotmail dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 16 Aug 2011 22:35:02 +0000 (UTC)
- Subject: Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)
- References: <20110816205046.44176B21AC@azwildcat.mtv.corp.google.com>
On Tue, 16 Aug 2011, Sriraman Tallam wrote:
> Index: libgcc/config/i386/t-cpuinfo
> ===================================================================
> --- libgcc/config/i386/t-cpuinfo (revision 0)
> +++ libgcc/config/i386/t-cpuinfo (revision 0)
> @@ -0,0 +1,2 @@
> +# This is an endfile
> +LIB2ADD += $(srcdir)/config/i386/i386-cpuinfo.c
What do you mean by this comment? That it's linked in like crt*end*.o?
It looks to me like a normal libgcc object, not an endfile.
> Index: libgcc/config/i386/i386-cpuinfo.c
> ===================================================================
> --- libgcc/config/i386/i386-cpuinfo.c (revision 0)
> +++ libgcc/config/i386/i386-cpuinfo.c (revision 0)
> @@ -0,0 +1,275 @@
> +/* Copyright (C) 2011 Free Software Foundation, Inc.
> + * Contributed by Sriraman Tallam <tmsriram@google.com>.
Please format in the normal way; no leading "*" on each comment line.
> +#include <string.h>
Don't include headers not provided by GCC in libgcc without checking
inhibit_libc, to avoid bootstrap problems. Declaring just the functions
you need is safer here than including a system header.
> +#ifdef __GNUC__
Such a conditional does not make sense in libgcc code.
> +/* This function will be linked in to binaries that need to look up
> + CPU information. */
> +
> +void
> +__cpu_indicator_init(void)
Format according to the GNU Coding Standards.
You appear not to have added any symbol versions; do you have a particular
rationale for these functions being linked separately into each executable
and shared library needing them, rather than being exported from the
shared libgcc?
--
Joseph S. Myers
joseph@codesourcery.com