RE: [Xen-devel] Bizarre compile/link problem from minor change

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

OK, here's another try, but only gets 95% of the way there...

1) Add the #ifdef __HAVE_ARCH_MEMCPY in string.c and remove
   the #undef so that string.c is more "normal."
2) In include/asm-x86/x86_32/string.h, change the #define
   for memcpy to be a static inline function.

Then everything works except for one small problem...
vmx.c now reports a strange cc warning: "'memcpy' defined
but not used" (... whatever that means in this context?!?)
Since the default CFLAGS uses -Werror to turn warnings into
compiler errors, the make fails.

Removing the -Werror from CFLAGS (which is obviously not
desirable... but this warning is entirely useless), allows
the make to complete successfully.

Can anyone figure out a way to resolve this strange warning
so that string.c can go back to "normal"?

I realize that this is not a high-priority problem, but files
that are 99.9% identical to something else but the remaining
0.01% is different for some odd reason are bothersome to me.
I spent a good half day earlier this year trying to
figure out what was going on (and eventually discovering
the strange #undef) and I doubt I will be the last.

Dan

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: Tuesday, January 11, 2005 2:22 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Bizarre compile/link problem from 
> minor change 
> 
> 
> Structure assignments (e.g., struct foo x = y) sometimes get turned
> into calls to memcpy() by GCC. It doesn't run the emitted memcpy()
> through CPP so our macro-based implementation in the header files
> doesn't get used. We therefore *always* have the implementation in
> common/string.c as a "fall back". 
> 
> I think some flag like '-ffreestanding' is supposed to avoid this
> behaviour, but it's a pretty small issue and I don't know whether that
> flag could have other unfortunate side effects.
> 
>  -- Keir
> 
> PS. If you really do want a non-macro implementation of memcpy() for
> IA64 then we can add __HAVE_ARCH_MEMCPY for you. We just won't define
> that for x86, and we cannot remove the #undef.
> 
> > Perhaps someone who is smarter (or at least has more
> > compiler/linker knowledge than me :-) can solve this
> > bizarre problem:
> > 
> > I have been annoyed for some time with a hack that's
> > in xen/common/string.c... For the routine memcpy(),
> > there is an #undef right before it.  Why not do
> > this properly and use the #ifndef __HAVE_ARCH_MEMCPY
> > around it, like all the other routines?  So I tried
> > it.  And got an undefined reference reported by the
> > linker from arch/x86/vmx.o.
> > 
> > Looking at arch/x86/vmx.c, there's no reference to
> > memcpy.  And if you look at the output from cpp, there's
> > no reference to memcpy.  If you add a #include
> > for <xen/string.h> after <xen/lib.h>, it doesn't
> > fix anything.
> > 
> > To try to force the compiler to tell me where the
> > problem lay, AHA, I added a line at the beginning
> > of the source:
> > 
> > void memcpy(void) {}
> > 
> > thinking that the compiler would surely report a
> > mismatch.  It didn't and the compile/link succeeds!
> > 
> > Clearly adding this line is not a nice solution.
> > Can anyone come up with a better one?   (Other than
> > just leaving string.c as is...)  Please try your
> > solution yourself... I tried a few and couldn't find
> > one that worked.  If you find one, kindly reply to
> > this post.
> > 
> > Maybe I'm just tired....
> > 
> > Dan
> > 
> > 
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, 
> almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
>  -=- MIME -=- > 
> Perhaps someone who is smarter (or at least has more
> compiler/linker knowledge than me :-) can solve this
> bizarre problem:
> 
> I have been annoyed for some time with a hack that's
> in xen/common/string.c... For the routine memcpy(),
> there is an #undef right before it.  Why not do
> this properly and use the #ifndef __HAVE_ARCH_MEMCPY
> around it, like all the other routines?  So I tried
> it.  And got an undefined reference reported by the
> linker from arch/x86/vmx.o.
> 
> Looking at arch/x86/vmx.c, there's no reference to
> memcpy.  And if you look at the output from cpp, there's
> no reference to memcpy.  If you add a #include
> for <xen/string.h> after <xen/lib.h>, it doesn't
> fix anything.
> 
> To try to force the compiler to tell me where the
> problem lay, AHA, I added a line at the beginning
> of the source:
> 
> void memcpy(void) {}
> 
> thinking that the compiler would surely report a
> mismatch.  It didn't and the compile/link succeeds!
> 
> Clearly adding this line is not a nice solution.
> Can anyone come up with a better one?   (Other than
> just leaving string.c as is...)  Please try your
> solution yourself... I tried a few and couldn't find
> one that worked.  If you find one, kindly reply to
> this post.
> 
> Maybe I'm just tired....
> 
> Dan
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 
> 


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel