Re: [Xen-devel] tools/fuzz fails due build, osstest did not notice

["Jan Beulich" <JBeulich@xxxxxxxx>]

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