[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] tools/fuzz fails due build, osstest did not notice
>>> On 20.09.18 at 20:19, <christopher.w.clark@xxxxxxxxx> wrote: > I've just encountered this problem, building with the master branch of > OpenEmbedded and Yocto's poky, with compiler flags that include > _FORTIFY_SOURCE=2 -msse3 > with gcc 8.2.0. > > Xen's x86_emulator header file does: > #pragma GCC target("no-sse") > > The pragma was introduced in Xen commit 79136f26, to prevent the compiler from > using registers otherwise used by inline memset and memcpy. > > Setting _FORTIFY_SOURCE causes the use of always_inline variants of memset and > memcpy which use those instructions, which is now causing the inline to fail. > > The behaviour is described in the GCC bugzilla here: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71991 > > {quote} > cat fuzz-emul.i > __attribute__((__always_inline__)) a() {} > #pragma GCC target "no-sse" > b() { a(); } > > Where 'a' is 'memcpy' and 'b' is a function in xen. > > Can you Honza also take a look r251333 where we started to reject such > code? > {quote} > > links to this GCC change: > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=251333 > > Would the below Xen patch, which adds undefs for _FORTIFY_SOURCE just for the > two binaries which are affected be acceptable? It allows for use of > _FORTIFY_SOURCE with the rest of the build. In a suitably massaged form I think this could be acceptable. It needs to fully describe the reasons for the addition, and if at all possible it should add the -U only for affected compilers (the bugzilla entry you found suggests to me that this has been fixed earlier this year). That said, I'm certainly feeling a little uneasy about adding such overrides to the build flags "just for the two binaries which are affected". How can we be certain the same issue won't creep in elsewhere? Furthermore it looks as if _FORTIFY_SOURCE implied __always_inline__ solely because its use takes a minimum level of optimization as a prereq. If that's indeed the case, un-defining that symbol won't help builds which enable sufficient optimization, irrespective of the use of _FORTIFY_SOURCE. Yet I'd prefer to see the root of the issue addressed, not just one particular incarnation. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |