[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Bizarre compile/link problem from minor change
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |