Re: [PATCH] Use -fno-unit-at-a-time if gcc supports it

[David Mosberger-Tang]

For what it's worth, it was straight-forward to get the ia64 linux
kernel to compile & boot with the latest gcc snapshot.  I could make a
patch, if anyone cares, but it was mostly trival stuff: a small
cleanup in init_task.c and a few changes in init.h/compiler.h to use
"attribute ((used))".

Even the wait-channels seem to come out right, though I'm not sure
what's being done there is guaranteed to continue to work as the
compiler gets more aggressive...

	--david
--
Interested in learning more about IA-64 Linux?  Try http://www.lia64.org/book/

>>>>> On Sat, 06 Sep 2003 09:10:10 +0200, Jan Hubicka <jh@xxxxxxx> said:

  >> On Fri, 2003-09-05 at 11:17, Andreas Jaeger wrote:
  >> 
  >> 
  >> > Since unit-at-a-time has better inlining heuristics the better
  >> way is > to add the used attribute - but that takes some time.
  >> The short-term > solution would be to add the compiler flag,
  >> 
  >> Won't we get a linker error if a static symbol is used but
  >> optimized-away?  It shouldn't be hard to fix the n linker errors
  >> that crop up.

  Jan> Yes, you get linker error.  You may also run into
  Jan> misscompilation assuiming that function is static and it is
  Jan> both called by hand in asm and by function call and there is
  Jan> missing attribute used and asmlinkage definition.  In that case
  Jan> GCC would conclude to change into register calling convention
  Jan> on i386 breaking asm code.

  Jan> I would expect this to be rare as functions tends to be used
  Jan> either by assembly or by normal code but not by both.
  >>  And why are we using static symbols in inline assembly outside
  >> of the compilation scope?

  Jan> The toplevel asm statements are common source of this at least
  Jan> in glibc.  I didn't look much into the kernel sources.

  Jan> I would be very happy if someone did look on that.  It may be
  Jan> well possible that implementing tricks you do currently with
  Jan> toplevel asm staements would need further extensions in GCC now
  Jan> and it would be nice to know about that.

  Jan> For instance it used to be possible to force function to go
  Jan> into given section by changing the section by hand, but now you
  Jan> have to use section attribute (that is cleaner anyway)
  >>  Anyhow, if it generates an error, this isn't hard to fix.
  >> 
  >> Here is the start...
  >> 
  >> Robert Love
  >> 
  >> 
  >> --- linux-rml/include/linux/compiler.h Fri Sep 5 11:57:56 2003
  >> +++ linux/include/linux/compiler.h Fri Sep 5 12:02:02 2003 @@
  >> -74,6 +74,19 @@ #define __attribute_pure__ /* unimplemented */
  >> #endif
  >> 
  >> +/* + * As of gcc 3.2, we can mark a function as 'used' and gcc
  >> will assume that, + * even if it does not find a reference to it
  >> in any compilation unit.  We + * need this for gcc 3.4 and
  >> beyond, which can optimize on a program-wide + * scope, and not
  >> just one file at a time, to avoid static symbols being + *
  >> discarded.  + */ +#if (__GNUC__ == 3 && __GNUC_MINOR__ > 1) ||
  >> __GNUC__ > 3 +#define __attribute_used__ __attribute__((used))
  >> +#else +#define __attribute_used__ /* unimplemented */ +#endif +
  Jan> I believe there is little trick - attribute used works either
  Jan> for variables or functions.  Functions can be marked as used
  Jan> only for GCC 3.4+ if I am right, so you may need
  Jan> __attribute_used_function__ and __attribute_used_variable__
  Jan> macros for that.

  Jan> Honza
  >> /* This macro obfuscates arithmetic on a variable address so that
  >> gcc shouldn't recognize the original var, and make assumptions
  >> about it */ #define RELOC_HIDE(ptr, off) \
  >> 
  >> 
  Jan> - To unsubscribe from this list: send the line "unsubscribe
  Jan> linux-kernel" in the body of a message to
  Jan> majordomo@xxxxxxxxxxxxxxx More majordomo info at
  Jan> http://vger.kernel.org/majordomo-info.html Please read the FAQ
  Jan> at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/