Date: Mon, 27 Jun 2016 12:00:12 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: toolchain@FreeBSD.org Subject: Cross-building with -fsanitize [was Re: Brokenness in i386 cross-build] Message-ID: <e102c2d6-b134-89ad-043c-d78c61ba7332@FreeBSD.org> In-Reply-To: <c6dbd0ae-dad4-cdd6-392d-88d4c6acf6bd@delphij.net> References: <201606270615.u5R6FENe091341@slippy.cwsent.com> <c6dbd0ae-dad4-cdd6-392d-88d4c6acf6bd@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--OhVs886cbAfkxwMTDjGXXt6tCHt9BkLFp
Content-Type: multipart/mixed; boundary="eoiRWUDkDBcwjJXVlRKqOWcrhkk5nmvp1"
From: Bryan Drewery <bdrewery@FreeBSD.org>
To: Dimitry Andric <dim@FreeBSD.org>
Cc: toolchain@FreeBSD.org
Message-ID: <e102c2d6-b134-89ad-043c-d78c61ba7332@FreeBSD.org>
Subject: Cross-building with -fsanitize [was Re: Brokenness in i386
cross-build]
References: <201606270615.u5R6FENe091341@slippy.cwsent.com>
<c6dbd0ae-dad4-cdd6-392d-88d4c6acf6bd@delphij.net>
In-Reply-To: <c6dbd0ae-dad4-cdd6-392d-88d4c6acf6bd@delphij.net>
--eoiRWUDkDBcwjJXVlRKqOWcrhkk5nmvp1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Using -fsanitize with WITH_SYSTEM_COMPILER (meaning a --sysroot and not
a default built-in path and using /usr/bin/cc), or an external compiler,
lacks proper support for building of all target cross-archs.
There's some jumbled back and forth context below my mail about it as wel=
l.
Normally without WITH_SYSTEM_COMPILER clang will compute the path to the
libusan*.a files by the path with which it was executed. This is for
the libclang_rt lookups. That is normally going to be
WORLDTMP/usr/bin/../lib/... Don't forget that WORLDTMP is our sysroot.
When we use WITH_SYSTEM_COMPILER it will build with /usr/bin/cc rather
than the WORLDTMP one. Thus it looks for the libusan support on the host=
:
>> /usr/bin/../lib/clang/3.8.0/lib/freebsd/libclang_rt.ubsan_standalone-i=
386.a
We do actually build the proper libclang_rt/libusan files for the
cross-build and install them into the sysroot.
This path comes from CompilerInvocation::GetResourcesPath() which lacks
a run-time override or --sysroot or -B support.
We only ever build the native libusan files and if WITH_LIB32 is
supported and enabled then you also get the i386.a files.
If you build i386 from amd64 WITH_SYSTEM_COMPILER(default) and the host
has WITHOUT_LIB32, then you will not have the
/usr/lib/clang/3.8.0/lib/freebsd/libclang_rt.ubsan_standalone-i386.a
file that is found by the running /usr/bin/cc when trying to use
-fsanitize and -target=3Di386.
I'm not sure if it is proper for clang to use its internal versions here
or perhaps use the sysrooted versions. The ResourcesPath seems to also
affect the internal header paths for builtin includes. So we should be
cautious with it. As Xin Li pointed out we could possibly add the
sysroot in only for the libusan/libclang_rt lookups.
If clang should only use its own versions of these .a files even with a
--sysroot then we need to build the libusan*.a files for every arch that
we support for the clang that is installed. Just as we build -target
support for every version of clang that we support for the clang that is
installed.
Hope this all made sense.
As for the build breakage, there is only 1 thing (a test) in the tree
currently using -fsanitize. So we can just workaround it for now by
disabling cross-build for it.
More context follows.
On 6/27/16 12:30 AM, Xin Li wrote:
> Could you please modify the patch to add a comment of XXX/TODO that thi=
s
> is a workaround? (Adding Dmitry; I think this shall be solved at
> toolchain level. I'm not totally against applying the workaround for
> now though.)
>=20
> =3D=3D=3D
>=20
> It seems that in
> collectSanitizerRuntimes(contrib/llvm/tools/clang/lib/Driver/Tools.cpp:=
2826
> then in 2852, then eventually 2756) we prefixed the library names with
> hardcoded path, derived from getDriver().ResourceDir, which in turn
> would give /usr/bin/.. without considering sysroot setting.
>=20
> So in effect we are passing something like:
>=20
> -whole-archive
> /usr/bin/../lib/clang/3.8.0/lib/freebsd/libclang_rt.ubsan_standalone-i3=
86.a
> -no-whole-archive
>=20
> To ld(1), while we really need to pass:
>=20
> -whole-archive
> ${sysroot}/usr/bin/../lib/clang/3.8.0/lib/freebsd/libclang_rt.ubsan_sta=
ndalone-i386.a
> -no-whole-archive
>=20
> Which I'm not familiar enough with the compiler internals to comfortabl=
y
> tell if we would break something else by blindly prefixing the result
> from ResourceDir.
>=20
> Cheers,
>=20
>> > In message <20160626215850.GB79880@FreeBSD.org>, Glen Barber writes:=
>>> >>
>>> >>
>>> >> --A6N2fC+uXW/VQSAv
>>> >> Content-Type: text/plain; charset=3Dus-ascii
>>> >> Content-Disposition: inline
>>> >> Content-Transfer-Encoding: quoted-printable
>>> >>
>>> >> Confirmed, the build fails.
>>> >>
>>> >>
>>> >> /usr/src/contrib/netbsd-tests/lib/libc/ssp/h_gets.c:40: warning: w=
arning: t=3D
>>> >> his program uses gets(), which is unsafe.
>>> >> t_mktemp.o: In function `atfu_mktemp_not_exist_body':
>>> >> /usr/src/contrib/netbsd-tests/lib/libc/stdio/t_mktemp.c:47: warnin=
g: warnin=3D
>>> >> g: mktemp() possibly used unsafely; consider using mkstemp()
>>> >> /usr/obj/i386.i386/usr/src/tmp/usr/bin/ld:
>>> /usr/bin/../lib/clang/3.8.0/lib/=3D
>>> >> freebsd/libclang_rt.ubsan_standalone-i386.a: No such file: No such=
file or =3D
>>> >> directory
>>> >> cc: error: linker command failed with exit code 1 (use -v to see i=
nvocation)
>>> >> --- h_raw.full ---
>>> >> *** [h_raw.full] Error code 1
>>> >>
>>> >> make[7]: stopped in /usr/src/lib/libc/tests/ssp
--=20
Regards,
Bryan Drewery
--eoiRWUDkDBcwjJXVlRKqOWcrhkk5nmvp1--
--OhVs886cbAfkxwMTDjGXXt6tCHt9BkLFp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJXcXe9AAoJEDXXcbtuRpfPtGoIALMrf2cBqP51xxA6NS5iN1io
lAoa5wtGybvu5k7HGEszHrJP17kUiTEEUOI+4qqoVzD/zd/Z9auyFxSWG21Zbnwn
78+XrviE16fhWzhQBoGosw/vjUOwZ5HxNwfjJiAihldXgXzsGIeNjffcrNS7lbJe
6ZvSXGVboS+E7FdGMaAjqEneThpV+hr+RRa2w9rA1L0la5MklyjZUEmzZCKlYls4
24Wyt0hfr3ApacLMOXxiX+jj5eoJID/L3q1h03CxlaTiWdejKweGd9W3YzdGM2sP
EVa1wm3CfwQC85WbA8AM/NCi903ZQMv2bt30SJ9oUmlaiMXq/ryxU0+Kk9J0y/I=
=o+WQ
-----END PGP SIGNATURE-----
--OhVs886cbAfkxwMTDjGXXt6tCHt9BkLFp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e102c2d6-b134-89ad-043c-d78c61ba7332>