From: David Mosberger-Tang <David.Mosberger@acm.org>
To: Jan Hubicka <jh@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Use -fno-unit-at-a-time if gcc supports it
Date: 06 Sep 2003 01:10:57 -0700 [thread overview]
Message-ID: <ugbrty49ri.fsf@panda.mostang.com> (raw)
In-Reply-To: <sFmW.78P.13@gated-at.bofh.it>
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@suse.cz> 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@vger.kernel.org More majordomo info at
Jan> http://vger.kernel.org/majordomo-info.html Please read the FAQ
Jan> at http://www.tux.org/lkml/
next parent reply other threads:[~2003-09-06 8:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <sqnW.3zE.13@gated-at.bofh.it>
[not found] ` <sqHd.3Yj.1@gated-at.bofh.it>
[not found] ` <srtA.53H.1@gated-at.bofh.it>
[not found] ` <sFmW.78P.13@gated-at.bofh.it>
2003-09-06 8:10 ` David Mosberger-Tang [this message]
2003-09-08 20:32 ` [PATCH] Use -fno-unit-at-a-time if gcc supports it David Mosberger
2003-09-05 0:47 Andi Kleen
2003-09-05 1:05 ` Aaron Lehmann
2003-09-05 1:24 ` Andi Kleen
2003-09-05 5:37 ` Jan Hubicka
2003-09-05 17:27 ` Andi Kleen
2003-09-05 17:59 ` Jeff Garzik
2003-09-06 7:08 ` Jan Hubicka
2003-09-05 14:54 ` Linus Torvalds
2003-09-05 15:17 ` Andreas Jaeger
2003-09-05 16:16 ` Robert Love
2003-09-05 16:10 ` Andreas Jaeger
2003-09-06 7:06 ` Jan Hubicka
2003-09-05 17:19 ` Jakub Jelinek
2003-09-05 17:30 ` Andi Kleen
2003-09-08 9:48 ` Helge Hafting
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ugbrty49ri.fsf@panda.mostang.com \
--to=david.mosberger@acm.org \
--cc=jh@suse.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox