From: Keith Owens <kaos@ocs.com.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] Missing EXPORT_SYMBOL memset
Date: Sat, 13 Apr 2002 01:55:13 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590701905444@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590701905441@msgid-missing>
On Sat, 13 Apr 2002 03:38:40 +0200,
Andreas Schwab <schwab@suse.de> wrote:
>Keith Owens <kaos@ocs.com.au> writes:
>
>|> On Fri, 12 Apr 2002 17:05:37 +0200,
>|> Andreas Schwab <schwab@suse.de> wrote:
>|> >GCC 3 may generate calls to memset, so we need to export it to modules.
>|>
>|> If gcc does that the code does not use the arch tuned memset. Also the
>|> memset function is only generated if __HAVE_ARCH_MEMSET is undefined,
>|> but include/asm-ia64/string.h defines __HAVE_ARCH_MEMSET. We would be
>|> better off teaching gcc not to generate calls to memset where we do not
>|> want them so the kernel gets the code that we want, not what gcc thinks
>|> might be a good idea.
>
>There is no way for gcc to see the memset macro when it generates the call
>to the memset function. And there isn't much lost anyway, since the macro
>is just there to call __bzero vs. __memset_generic (aka memset), the
>difference is just one parameter more or less.
I know about the "gcc decides to insert memset after cpp phase"
problem. When it occurred in the past (it used to happen with gcc 2.7
in 2.[02] kernels) the response was always to change the source code to
prevent gcc making this wrong decision. Adding and exporting a memset
function in the kernel is wrong, we need to fix gcc or change the
source code.
next prev parent reply other threads:[~2002-04-13 1:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-12 15:05 [Linux-ia64] Missing EXPORT_SYMBOL memset Andreas Schwab
2002-04-13 1:28 ` Keith Owens
2002-04-13 1:38 ` Andreas Schwab
2002-04-13 1:55 ` Keith Owens [this message]
2002-04-13 1:57 ` David Mosberger
2002-04-13 1:57 ` Andreas Schwab
2002-04-13 2:00 ` David Mosberger
2002-04-13 2:10 ` David Mosberger
2002-04-13 2:17 ` Keith Owens
2002-04-13 2:21 ` David Mosberger
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=marc-linux-ia64-105590701905444@msgid-missing \
--to=kaos@ocs.com.au \
--cc=linux-ia64@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.