Message ID | 1397041487-28477-1-git-send-email-peter.maydell@linaro.org |
---|---|
State | Accepted |
Commit | 0a9077ea144a7e6a6f456b94e2d2eaad21e74d34 |
Headers | show |
On 10 April 2014 17:31, Michael S. Tsirkin <mst@redhat.com> wrote: > On Wed, Apr 09, 2014 at 12:04:47PM +0100, Peter Maydell wrote: >> MacOSX clang silently swallows unrecognized -f options when doing a link >> with '-framework' also on the command line, so to detect support for >> the various -fstack-protector options we must do a plain .c to .o compile, >> not a complete compile-and-link. >> >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > > Hmm it worries me a bit that we aren't passing it to linker: > might break some builds in case compiler has a working > protector but linker doesn't. Given we both compile and link (in configure) with the same $compiler binary, this seems vanishingly unlikely. > configure: check -c each time we run compiler > > Some warnings/errors only surface if you run compiler > without a linker. Run both on each test. > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > diff --git a/configure b/configure > index eb0e7bb..8adc72b 100755 > --- a/configure > +++ b/configure > @@ -102,6 +102,7 @@ compile_object() { > compile_prog() { > local_cflags="$1" > local_ldflags="$2" > + do_cc $QEMU_CFLAGS -c $local_cflags -o $TMPO $TMPC > do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags > } > That's a lot of extra compiles and configure isn't exactly a speed demon as it is... thanks -- PMM
On Thu, Apr 10, 2014 at 05:37:31PM +0100, Peter Maydell wrote: > On 10 April 2014 17:31, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Wed, Apr 09, 2014 at 12:04:47PM +0100, Peter Maydell wrote: > >> MacOSX clang silently swallows unrecognized -f options when doing a link > >> with '-framework' also on the command line, so to detect support for > >> the various -fstack-protector options we must do a plain .c to .o compile, > >> not a complete compile-and-link. > >> > >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > > > > Hmm it worries me a bit that we aren't passing it to linker: > > might break some builds in case compiler has a working > > protector but linker doesn't. > > Given we both compile and link (in configure) with the > same $compiler binary, this seems vanishingly unlikely. True - I really meant libtool but we don't test it ATM so we can leave that for another day. OK fair enough: Reviewed-by: Michael S. Tsirkin <mst@redhat.com> > > configure: check -c each time we run compiler > > > > Some warnings/errors only surface if you run compiler > > without a linker. Run both on each test. > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > > > > > diff --git a/configure b/configure > > index eb0e7bb..8adc72b 100755 > > --- a/configure > > +++ b/configure > > @@ -102,6 +102,7 @@ compile_object() { > > compile_prog() { > > local_cflags="$1" > > local_ldflags="$2" > > + do_cc $QEMU_CFLAGS -c $local_cflags -o $TMPO $TMPC > > do_cc $QEMU_CFLAGS $local_cflags -o $TMPE $TMPC $LDFLAGS $local_ldflags > > } > > > > That's a lot of extra compiles and configure isn't > exactly a speed demon as it is... > > thanks > -- PMM
On 10 April 2014 18:51, Michael S. Tsirkin <mst@redhat.com> wrote:
> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Thanks; patch applied to master.
-- PMM
On 04/09/2014 09:04 PM, Peter Maydell wrote: > MacOSX clang silently swallows unrecognized -f options when doing a link > with '-framework' also on the command line, so to detect support for > the various -fstack-protector options we must do a plain .c to .o compile, > not a complete compile-and-link. > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org> > --- > This should be a pretty safe change and it prevents clang/MacOSX > builds from spewing a warning on every C file compilation, so I'd > like to get it into 2.0. > > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index eb0e7bb..c85475f 100755 > --- a/configure > +++ b/configure > @@ -1448,7 +1448,7 @@ done > if test "$stack_protector" != "no" ; then > gcc_flags="-fstack-protector-strong -fstack-protector-all" > for flag in $gcc_flags; do > - if compile_prog "-Werror $flag" "" ; then > + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then > QEMU_CFLAGS="$QEMU_CFLAGS $flag" > LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" > break > My cross environment fails after this patch on "-fstack-protector-all". Without the patch, gcc for test program gets additional "-m64 -g -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64" (the last one is mine, passed via --extra-ldflags=), fails with an error (below). With the patch, the configure script thinks everything is fine and fails on "ERROR: zlib check failed". Why is this happening? Thanks. powerpc64-linux-gcc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common --sysroot=/home/alexey/crosslib/qemu-build-lib-fc19/ -isystem /home/alexey/crosslib/qemu-build-lib-fc19/usr/include -D__EXCEPTIONS -D__LONG_DOUBLE_128__ -D__NO_INLINE__ -Wno-redundant-decls -Wno-missing-prototypes -Wmissing-include-dirs -Wno-system-headers -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror -fstack-protector-strong -o /tmp/qemu-conf-24556-2284-15038.exe /tmp/qemu-conf-31026-2284-18135.c -m64 -g -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64 powerpc64-linux-gcc: error: unrecognized command line option '-fstack-protector-strong' powerpc64-linux-gcc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common --sysroot=/home/alexey/crosslib/qemu-build-lib-fc19/ -isystem /home/alexey/crosslib/qemu-build-lib-fc19/usr/include -D__EXCEPTIONS -D__LONG_DOUBLE_128__ -D__NO_INLINE__ -Wno-redundant-decls -Wno-missing-prototypes -Wmissing-include-dirs -Wno-system-headers -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror -fstack-protector-all -o /tmp/qemu-conf-24556-2284-15038.exe /tmp/qemu-conf-31026-2284-18135.c -m64 -g -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64 /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: cannot find -lssp_nonshared /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: cannot find -lssp collect2: error: ld returned 1 exit status
On 04/11/2014 10:34 PM, Alexey Kardashevskiy wrote: > On 04/09/2014 09:04 PM, Peter Maydell wrote: >> MacOSX clang silently swallows unrecognized -f options when doing a link >> with '-framework' also on the command line, so to detect support for >> the various -fstack-protector options we must do a plain .c to .o compile, >> not a complete compile-and-link. >> >> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> >> --- >> This should be a pretty safe change and it prevents clang/MacOSX >> builds from spewing a warning on every C file compilation, so I'd >> like to get it into 2.0. >> >> configure | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/configure b/configure >> index eb0e7bb..c85475f 100755 >> --- a/configure >> +++ b/configure >> @@ -1448,7 +1448,7 @@ done >> if test "$stack_protector" != "no" ; then >> gcc_flags="-fstack-protector-strong -fstack-protector-all" >> for flag in $gcc_flags; do >> - if compile_prog "-Werror $flag" "" ; then >> + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then >> QEMU_CFLAGS="$QEMU_CFLAGS $flag" >> LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" >> break >> > > My cross environment fails after this patch on "-fstack-protector-all". > Without the patch, gcc for test program gets additional "-m64 -g > -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64" (the last one is > mine, passed via --extra-ldflags=), fails with an error (below). With the > patch, the configure script thinks everything is fine and fails on "ERROR: > zlib check failed". > > Why is this happening? Thanks. This helps. No idea why. Any ideas? :) @@ -1448,7 +1452,7 @@ done if test "$stack_protector" != "no" ; then gcc_flags="-fstack-protector-strong -fstack-protector-all" for flag in $gcc_flags; do - if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC "" ; then QEMU_CFLAGS="$QEMU_CFLAGS $flag" LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" break > > > > powerpc64-linux-gcc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef > -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common > --sysroot=/home/alexey/crosslib/qemu-build-lib-fc19/ -isystem > /home/alexey/crosslib/qemu-build-lib-fc19/usr/include -D__EXCEPTIONS > -D__LONG_DOUBLE_128__ -D__NO_INLINE__ -Wno-redundant-decls > -Wno-missing-prototypes -Wmissing-include-dirs -Wno-system-headers > -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror > -fstack-protector-strong -o /tmp/qemu-conf-24556-2284-15038.exe > /tmp/qemu-conf-31026-2284-18135.c -m64 -g > -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64 > powerpc64-linux-gcc: error: unrecognized command line option > '-fstack-protector-strong' > powerpc64-linux-gcc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef > -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common > --sysroot=/home/alexey/crosslib/qemu-build-lib-fc19/ -isystem > /home/alexey/crosslib/qemu-build-lib-fc19/usr/include -D__EXCEPTIONS > -D__LONG_DOUBLE_128__ -D__NO_INLINE__ -Wno-redundant-decls > -Wno-missing-prototypes -Wmissing-include-dirs -Wno-system-headers > -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers > -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror > -fstack-protector-all -o /tmp/qemu-conf-24556-2284-15038.exe > /tmp/qemu-conf-31026-2284-18135.c -m64 -g > -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64 > /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: > cannot find -lssp_nonshared > /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: > cannot find -lssp > collect2: error: ld returned 1 exit status > > > >
On 04/12/2014 12:24 AM, Alexey Kardashevskiy wrote: > On 04/11/2014 10:34 PM, Alexey Kardashevskiy wrote: >> On 04/09/2014 09:04 PM, Peter Maydell wrote: >>> MacOSX clang silently swallows unrecognized -f options when doing a link >>> with '-framework' also on the command line, so to detect support for >>> the various -fstack-protector options we must do a plain .c to .o compile, >>> not a complete compile-and-link. >>> >>> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> >>> --- >>> This should be a pretty safe change and it prevents clang/MacOSX >>> builds from spewing a warning on every C file compilation, so I'd >>> like to get it into 2.0. >>> >>> configure | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/configure b/configure >>> index eb0e7bb..c85475f 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -1448,7 +1448,7 @@ done >>> if test "$stack_protector" != "no" ; then >>> gcc_flags="-fstack-protector-strong -fstack-protector-all" >>> for flag in $gcc_flags; do >>> - if compile_prog "-Werror $flag" "" ; then >>> + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then >>> QEMU_CFLAGS="$QEMU_CFLAGS $flag" >>> LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" >>> break >>> >> >> My cross environment fails after this patch on "-fstack-protector-all". >> Without the patch, gcc for test program gets additional "-m64 -g >> -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64" (the last one is >> mine, passed via --extra-ldflags=), fails with an error (below). With the >> patch, the configure script thinks everything is fine and fails on "ERROR: >> zlib check failed". >> >> Why is this happening? Thanks. > > > This helps. No idea why. Any ideas? :) > > @@ -1448,7 +1452,7 @@ done > if test "$stack_protector" != "no" ; then > gcc_flags="-fstack-protector-strong -fstack-protector-all" > for flag in $gcc_flags; do > - if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then > + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC "" ; then > QEMU_CFLAGS="$QEMU_CFLAGS $flag" > LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" > break Ok. Here are 2 logs - "good" with the patch above, "bad" - without. > > > > >> >> >> >> powerpc64-linux-gcc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 >> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef >> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common >> --sysroot=/home/alexey/crosslib/qemu-build-lib-fc19/ -isystem >> /home/alexey/crosslib/qemu-build-lib-fc19/usr/include -D__EXCEPTIONS >> -D__LONG_DOUBLE_128__ -D__NO_INLINE__ -Wno-redundant-decls >> -Wno-missing-prototypes -Wmissing-include-dirs -Wno-system-headers >> -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs >> -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers >> -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror >> -fstack-protector-strong -o /tmp/qemu-conf-24556-2284-15038.exe >> /tmp/qemu-conf-31026-2284-18135.c -m64 -g >> -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64 >> powerpc64-linux-gcc: error: unrecognized command line option >> '-fstack-protector-strong' >> powerpc64-linux-gcc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 >> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef >> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common >> --sysroot=/home/alexey/crosslib/qemu-build-lib-fc19/ -isystem >> /home/alexey/crosslib/qemu-build-lib-fc19/usr/include -D__EXCEPTIONS >> -D__LONG_DOUBLE_128__ -D__NO_INLINE__ -Wno-redundant-decls >> -Wno-missing-prototypes -Wmissing-include-dirs -Wno-system-headers >> -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs >> -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers >> -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror >> -fstack-protector-all -o /tmp/qemu-conf-24556-2284-15038.exe >> /tmp/qemu-conf-31026-2284-18135.c -m64 -g >> -L/home/alexey/crosslib/qemu-build-lib-fc19/usr/lib64 >> /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: >> cannot find -lssp_nonshared >> /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: >> cannot find -lssp >> collect2: error: ld returned 1 exit status >> >> >> >> > >
On 11 April 2014 15:33, Alexey Kardashevskiy <aik@ozlabs.ru> wrote: > On 04/12/2014 12:24 AM, Alexey Kardashevskiy wrote: >> This helps. No idea why. Any ideas? :) >> >> @@ -1448,7 +1452,7 @@ done >> if test "$stack_protector" != "no" ; then >> gcc_flags="-fstack-protector-strong -fstack-protector-all" >> for flag in $gcc_flags; do >> - if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then >> + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC "" ; then >> QEMU_CFLAGS="$QEMU_CFLAGS $flag" >> LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" >> break This change causes the do_cc to always fail (you can see the compiler errors in the logs as it fails to find a file whose name is the empty string), so it means we don't use the -fstack-protector arguments. >>> /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: >>> cannot find -lssp_nonshared >>> /home/system/opt/cross/gcc-4.8.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/4.8.0/../../../../powerpc64-linux/bin/ld: >>> cannot find -lssp >>> collect2: error: ld returned 1 exit status If we do use the stack protector arguments then the next time we try to do a configure test which does a link then it fails like this, because your cross compile environment doesn't have the stack-protector libraries in it. You should probably add those, so you get the benefit of the stack protection, but we can work around this in configure by doing both a compile and a link check, as MST originally suggested. Patch to follow shortly. (Here's a linux perf tools patch which deals with a similar situation: https://lkml.org/lkml/2010/1/11/117 ) thanks -- PMM
diff --git a/configure b/configure index eb0e7bb..c85475f 100755 --- a/configure +++ b/configure @@ -1448,7 +1448,7 @@ done if test "$stack_protector" != "no" ; then gcc_flags="-fstack-protector-strong -fstack-protector-all" for flag in $gcc_flags; do - if compile_prog "-Werror $flag" "" ; then + if do_cc $QEMU_CFLAGS -Werror $flag -c -o $TMPO $TMPC ; then QEMU_CFLAGS="$QEMU_CFLAGS $flag" LIBTOOLFLAGS="$LIBTOOLFLAGS -Wc,$flag" break
MacOSX clang silently swallows unrecognized -f options when doing a link with '-framework' also on the command line, so to detect support for the various -fstack-protector options we must do a plain .c to .o compile, not a complete compile-and-link. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- This should be a pretty safe change and it prevents clang/MacOSX builds from spewing a warning on every C file compilation, so I'd like to get it into 2.0. configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)