WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] Bizarre compile/link problem from minor change
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 11 Jan 2005 09:22:17 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 11 Jan 2005 09:23:33 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: Your message of "Mon, 10 Jan 2005 16:35:36 PST." <516F50407E01324991DD6D07B0531AD51A951C@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>