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

From: David Mosberger-Tang
Date: Sat Sep 06 2003 - 03:30:09 EST


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/