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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.18 at 09:32, <olaf@xxxxxxxxx> wrote:
> Am Mon, 03 Sep 2018 06:35:42 -0600
> schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:
> 
>> what is the actual problem? The mere
>> listing of compiler flags passed does not make clear to me where the clash
>> is, or how it would surface.
> 
> As I noticed just now, it fails to build only in Tumbleweed. So in this 
> specific case osstest would have caught it only in a few years from now.
> 
> [   38s] make -C x86_instruction_emulator install
> [   38s] make[6]: Entering directory 
> '/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> s/fuzz/x86_instruction_emulator'
> [   38s] [ -L x86-emulate.h ] || ln -sf 
> /home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tools
> /fuzz/x86_instruction_emulator/../../../tools/tests/x86_emulator/x86-emulate.h
> [   38s] [ -L x86_emulate ] || ln -sf 
> /home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tools
> /fuzz/x86_instruction_emulator/../../../xen/arch/x86/x86_emulate
> [   38s] /usr/bin/gcc  -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall 
> -Wstrict-prototypes -Wdeclaration-after-statement 
> -Wno-unused-but-set-variable 
> -Wno-unused-local-typedefs   -O0 -fno-omit-frame-pointer 
> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF 
> .fuzz-emul.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -O2 -Wall 
> -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables 
> -fasynchronous-unwind-tables -fstack-clash-protection 
> -I/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> s/fuzz/x86_instruction_emulator/../../../tools/include -D__XEN_TOOLS__ -I.  
> -c -o 
> fuzz-emul.o fuzz-emul.c
> [   38s] In file included from /usr/include/features.h:428,   
> [   38s]                  from /usr/include/assert.h:35,
> [   38s]                  from fuzz-emul.c:1:
> [   38s] fuzz-emul.c: In function 'input_read':
> [   38s] /usr/include/bits/string_fortified.h:31:1: error: inlining failed 
> in call to always_inline 'memcpy': target specific option mismatch
> [   38s]  __NTH (memcpy (void *__restrict __dest, const void *__restrict 
> __src,
> [   38s]  ^~~~~
> [   38s] fuzz-emul.c:67:5: note: called from here
> [   38s]      memcpy(dst, &s->corpus->data[s->data_index], size);
> [   38s]      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [   38s] In file included from /usr/include/features.h:428,   
> [   38s]                  from /usr/include/assert.h:35,
> [   38s]                  from fuzz-emul.c:1:
> [   38s] /usr/include/bits/string_fortified.h:31:1: error: inlining failed 
> in call to always_inline 'memcpy': target specific option mismatch
> [   38s]  __NTH (memcpy (void *__restrict __dest, const void *__restrict 
> __src,
> [   38s]  ^~~~~
> [   38s] fuzz-emul.c:67:5: note: called from here
> [   38s]      memcpy(dst, &s->corpus->data[s->data_index], size);
> [   38s]      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [   38s] make[6]: *** 
> [/home/abuild/rpmbuild/BUILD/xen-4.12.20180831T120653.6164970942/non-dbg/tool
> s/fuzz/x86_instruction_emulator/../../../tools/Rules.mk:225: fuzz-emul.o] 
> Error 1
> 
> Appending -U_FORTIFY_SOURCE in tools/fuzz fixes it. Not sure why fuzz is 
> different from the rest of tools.

No idea here either, for the moment, even after looking at gcc's
ix86_can_inline_p() (which apparently is the function triggering the
diagnostic).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel