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: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Bizarre compile/link problem from minor change
From: dan.magenheimer@xxxxxx
Date: Tue, 11 Jan 2005 07:45:42 -0600 (CST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 11 Jan 2005 14:09:46 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
Importance: Normal
In-reply-to: <E1CoIEE-0000yE-00@xxxxxxxxxxxxxxxxx>
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>
References: Your message of "Mon, 10 Jan 2005 16:35:36 PST." <516F50407E01324991DD6D07B0531AD51A951C@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <E1CoIEE-0000yE-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: SquirrelMail/1.4.3a
Hmmm... so how does Linux get around what I'd imagine would
be the same problem?  Although admittedly it is a small issue,
it would be nice to get it right rather than just get it working.
A file like string.c is pretty generic and IMHO shouldn't have a
couple of very obscure Xen-specific hacks in it.
This is the kind of small issue that could cost Xensource a
lot of grief in a real world support environment.

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