Richard Henderson wrote:
>
> On Fri, Jun 16, 2000 at 07:20:03PM -0400, Tom Leete wrote:
> > By exporting it you take its address, which runs afoul of inlining.
>
> Do you have any idea what you're talking about?
>
> r~
Yes.
In current i386 memcpy is a macro. It inlines either
__constant_memcpy() or __memcpy(), themselves macros. I have
reason to know that explicit inlining is regarded as
paramount there.
To export memcpy it must be an addressable function.
static __inline__ void *memcpy(void *dest, void *src, size_t
len)
{
/* define me */
return dest;
}
will fail to inline for any compilation unit in which memcpy
is referenced directly -- ie wherever ksyms is.
inline void *memcpy(void *dest, void *src, size_t len)
{
/* define me */
return dest;
}
fails to provide an addressable copy.
This will work:
---
asm/string.h:
#define MEMCPY_CODE(d,s,l) { /* code */ return d; }
extern __inline__
void *memcpy(void *dest, void *src, sizet len)
MEMCPY_CODE(dest,src,len)
---
somewhere in arch/*/lib/ or arch/*/mm/
#include <asm/string.h>
void *memcpy(void *dest, void *src, sizet len)
MEMCPY_CODE(dest,src,len)
________________
The new C Standard also provides an inline construct for
this, but I havent tried any new std compilers yet. The
standard will break all the storage class modified inline
declarations in the kernel. One more backward flag, one of
these days.
Ref.
$ info gcc # node "C Extensions::Inline"
Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:13 EST