On Tue, Aug 16, 2011 at 3:35 PM, Joseph S. Myers <jos...@codesourcery.com> wrote: > 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 <tmsri...@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?
I did not realize I could just make shared libgcc export those symbols. I will make the changes you mentioned. Thanks, -Sri. > > -- > Joseph S. Myers > jos...@codesourcery.com >
