Magenheimer, Dan (HP Labs Fort Collins)
2005-Jan-11 00:35 UTC
[Xen-devel] Bizarre compile/link problem from minor change
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser
2005-Jan-11 09:22 UTC
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@lists.sourceforge.net > 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@lists.sourceforge.net 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
dan.magenheimer@hp.com
2005-Jan-11 13:45 UTC
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@lists.sourceforge.net >> 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@lists.sourceforge.net > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Magenheimer, Dan (HP Labs Fort Collins)
2005-Jan-12 23:51 UTC
RE: [Xen-devel] Bizarre compile/link problem from minor change
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@cl.cam.ac.uk] > Sent: Tuesday, January 11, 2005 2:22 AM > To: Magenheimer, Dan (HP Labs Fort Collins) > Cc: xen-devel@lists.sourceforge.net > 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@lists.sourceforge.net > > 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@lists.sourceforge.net > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser
2005-Jan-13 08:19 UTC
Re: [Xen-devel] Bizarre compile/link problem from minor change
> 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.I''ll check something into unstable. K. ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel