[Linux-ia64] Missing EXPORT_SYMBOL memset

[Linux-ia64] Missing EXPORT_SYMBOL memset

[Andreas Schwab]

GCC 3 may generate calls to memset, so we need to export it to modules.
For example, lvm requires it now, referenced from lvm.c:lvm_do_vg_rename.

--- linux/arch/ia64/kernel/ia64_ksyms.c.~1~	2002-04-11 12:02:05.000000000 +0200
+++ linux/arch/ia64/kernel/ia64_ksyms.c	2002-04-11 17:40:21.000000000 +0200
@@ -27,6 +27,10 @@
 EXPORT_SYMBOL(strtok);
 EXPORT_SYMBOL(strpbrk);
 
+#undef memset
+extern void *memset(void *, int, size_t);
+EXPORT_SYMBOL_NOVERS(memset);
+
 #include <linux/irq.h>
 EXPORT_SYMBOL(isa_irq_to_vector_map);
 EXPORT_SYMBOL(enable_irq);

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[Keith Owens]

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.

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[Andreas Schwab]

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.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[Keith Owens]

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.

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[David Mosberger]

>>>>> On Fri, 12 Apr 2002 17:05:37 +0200, Andreas Schwab <schwab@suse.de> said:

  Andreas> GCC 3 may generate calls to memset, so we need to export it
  Andreas> to modules.  For example, lvm requires it now, referenced
  Andreas> from lvm.c:lvm_do_vg_rename.

Yes.  Thanks for the patch.

	--david

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[Andreas Schwab]

Keith Owens <kaos@ocs.com.au> writes:

|> 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

It exists already, I didn't add anything.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[David Mosberger]

>>>>> On Sat, 13 Apr 2002 03:38:40 +0200, Andreas Schwab <schwab@suse.de> said:

  Andreas> There is no way for gcc to see the memset macro when it
  Andreas> generates the call to the memset function.  And there isn't
  Andreas> much lost anyway, since the macro is just there to call
  Andreas> __bzero vs. __memset_generic (aka memset), the difference
  Andreas> is just one parameter more or less.

Just fyi: the reason I split it up is because for ia64 its worthwhile
to special-case the memset-to-zero case (think stf.spill).  That code
isn't there yet, but I wanted to get things set up for it.  Of course,
memset can also check for this case dynamically, but from a logical
perspective, I like it better to make the bzero case explicit (and
save a taken branch in those cases where the compiler macro detects
memset-to-zero).

	--david

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[David Mosberger]

>>>>> On Sat, 13 Apr 2002 11:55:13 +1000, Keith Owens <kaos@ocs.com.au> said:

  Keith> I know about the "gcc decides to insert memset after cpp
  Keith> phase" problem.  When it occurred in the past (it used to
  Keith> happen with gcc 2.7 in 2.[02] kernels) the response was
  Keith> always to change the source code to prevent gcc making this
  Keith> wrong decision.

I don't see much wrong with gcc generating calls to memset().
What problem are you worried about?

	--david

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[Keith Owens]

On Fri, 12 Apr 2002 19:10:24 -0700, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Sat, 13 Apr 2002 11:55:13 +1000, Keith Owens <kaos@ocs.com.au> said:
>
>  Keith> I know about the "gcc decides to insert memset after cpp
>  Keith> phase" problem.  When it occurred in the past (it used to
>  Keith> happen with gcc 2.7 in 2.[02] kernels) the response was
>  Keith> always to change the source code to prevent gcc making this
>  Keith> wrong decision.
>
>I don't see much wrong with gcc generating calls to memset().
>What problem are you worried about?

Because those calls are generated after cpp has run so they do not use
#define memset.  We end up with two classes of memset, most using the
macro but a few using the function.  When this problem occurred in the
context of gcc 2.7 and 2.[02] kernels, the response was always to
change the source code to prevent gcc generating code that we did not
want.  If that decision is going to change, it needs to be run past l-k
first.

Re: [Linux-ia64] Missing EXPORT_SYMBOL memset

[David Mosberger]

>>>>> On Sat, 13 Apr 2002 12:17:05 +1000, Keith Owens <kaos@ocs.com.au> said:

  Keith> Because those calls are generated after cpp has run so they
  Keith> do not use #define memset.  We end up with two classes of
  Keith> memset, most using the macro but a few using the function.

Yes, I know that.

  Keith> When this problem occurred in the context of gcc 2.7 and
  Keith> 2.[02] kernels, the response was always to change the source
  Keith> code to prevent gcc generating code that we did not want.

So what would you have gcc rather do?  Generate the code inline?
I don't like that option at all.

	--david