Missing EXPORT_SYMBOL memset

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.

@@ -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, [email protected]
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."

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.

Keith Owens <[email protected]> writes:

|> On Fri, 12 Apr 2002 17:05:37 +0200, 
|> Andreas Schwab <[email protected]> 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, [email protected]
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."

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.

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

Keith Owens <[email protected]> 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, [email protected]
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."

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

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

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.

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