On Tue, Aug 30, 2016 at 02:50:03PM -0700, Matthew Macy wrote:
> 
> 
> 
>  ---- On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis <bro...@freebsd.org> 
> wrote ---- 
>  > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: 
>  > > It looks like there is something broken with the devel/llvm38 port or 
> external toolchain support has regressed: 
>  > >  
>  > >  
>  > > This works: 
>  > > make  XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 
> XCPP=/usr/local/bin/clang-cpp37  buildworld -j12 -s 
>  > >  
>  > > This fails: 
>  > >  make  XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 
> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s 
>  > >  
>  > > with: 
>  > >  
>  > > 
> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld:
>  
> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a:
>  No such file: No such file or directory 
>  > > clang-3.8: error: linker command failed with exit code 1 (use -v to see 
> invocation) 
>  >  
>  > I've fixed the install problem.  I'm rather confused about why clang 
>  > would try to link with sanitizer libraries when building source.  That's 
>  > certainly not default behavior. 
>  
> Thanks for the extremely prompt response to both issues. I haven't figured 
> out why svn has problems but the libc/tests failure can be traced back to the 
> following commit:
> 
> commit 3d2a537705eca33db3c523f4f92290d382aa7ab1
> Author: ngie <n...@freebsd.org>
> Date:   Fri Jan 2 05:40:02 2015 +0000
> 
>     Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 
> Jenkins
>     job
>     
>     The h_raw application doesn't do proper bounds checking without the option
>     being supplied via the build, which means that it doesn't throw signals 
> and
>     fail as expected
>     
>     PR: 196430
>     X-MFC with: r276479
> 
> diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh 
> b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> index 04adc67..362178f 100755
> --- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> +++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh
> @@ -360,6 +360,9 @@ raw_head()
>  raw_body()
>  {
>         prog="$(atf_get_srcdir)/h_raw"
> +       # Begin FreeBSD
> +       [ -x $prog ] || atf_skip "$prog is missing; skipping testcase"
> +       # End FreeBSD
>  
>         h_pass "$prog 9"
>         # Begin FreeBSD
> diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile
> index 1649cc2..7bc8660 100644
> --- a/lib/libc/tests/ssp/Makefile
> +++ b/lib/libc/tests/ssp/Makefile
> @@ -9,10 +9,7 @@ WARNS?=        2
>  
>  CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector
>  .if ${COMPILER_TYPE} == "clang"
> -# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0.
> -.if ${COMPILER_VERSION} < 30500
>  CFLAGS.h_raw+= -fsanitize=bounds
> -.endif

Thanks for hunting this down.

There's no strong reason to assume that a given clang has sanitizers
available.  In the current build system, you need a clang tree to build
the sanitizers, but the build process is separate.  If we're going to
enable sanitizers in tests, we need to do so conditionally so we don't
break the tests on non-x86 systems and so compiler installs don't need
to provide them.

-- Brooks

Attachment: signature.asc
Description: PGP signature

Reply via email to