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