This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH] Merge libsanitizer from upstream


Hi, I'm sorry for a late response.

On 19/10/17 13:52, Jakub Jelinek wrote:
On Mon, Oct 16, 2017 at 08:52:50PM +0200, Jakub Jelinek wrote:
The following patch is an attempt at libsanitizer merge from upstream.
Sadly libubsan has several ABI incompatible changes, dunno if we should
fight the mess and re-add backward compatibility back, or as the patch
does just bump soname, upstream clearly doesn't care about ABI compatibility
at all.

Bootstrapped/regtested on x86_64-linux and i686-linux, it would be nice to
get it tested on other targets (e.g. darwin, that breaks almost all the time
when doing merges, but no access to that).

Included is just the non-libsanitizer/ part plus GCC owned file changes
in libsanitizer (except regenerated ones), attached is bzip2ed full patch.

Thoughts on this?
Seems I've missed two test failures during the testing, this incremental patch ought
to fix that (with LTO we optimize away __asan_default_options and thus the
test fails, and libasan changed the env var handling, instead of having
handle_segv={0,1} it now has {0,1,2} modes and the old default 1 mode is now
the non-default mode 2, which the test relies on.

To answer my own question about possibility to avoid libubsan soname bump,
seems that is really not possible, because they removed already before
last merge __ubsan_handle_cfi_bad_type{,_abort} entrypoints (which we've
added back to make the library backwards compatible), but now they have
added __ubsan_handle_cfi_bad_type again with a different signature!
Argh!

Is the patch (the merge + this incremental) ok for trunk?

I think the patch is OK, just wondering about two things:

1) We have a bunch of GCC local patches, did you include them into a cumulative patch (I guess yes)? 2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them in GCC too?

-Maxim


2017-10-19  Jakub Jelinek  <jakub@redhat.com>

	* g++.dg/asan/default-options-1.C (__asan_default_options): Add
	used attribute.
	* g++.dg/asan/asan_test.C: Run with ASAN_OPTIONS=handle_segv=2
	in the environment.

--- gcc/testsuite/g++.dg/asan/default-options-1.C.jj	2015-10-29 09:14:39.000000000 +0100
+++ gcc/testsuite/g++.dg/asan/default-options-1.C	2017-10-19 12:09:26.367324880 +0200
@@ -3,7 +3,7 @@
  const char *kAsanDefaultOptions="verbosity=1 foo=bar";
extern "C"
-__attribute__((no_sanitize_address))
+__attribute__((no_sanitize_address, used))
  const char *__asan_default_options() {
    return kAsanDefaultOptions;
  }
--- gcc/testsuite/g++.dg/asan/asan_test.C.jj	2017-01-24 09:27:20.000000000 +0100
+++ gcc/testsuite/g++.dg/asan/asan_test.C	2017-10-19 12:06:27.453510604 +0200
@@ -8,6 +8,7 @@
  // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1" { target { ! run_expensive_tests } } }
  // { dg-additional-options "-msse2" { target { i?86-*-linux* x86_64-*-linux* } } }
  // { dg-additional-options "-D__NO_INLINE__" { target { *-*-linux-gnu } } }
+// { dg-set-target-env-var ASAN_OPTIONS "handle_segv=2" }
  // { dg-final { asan-gtest } }
#include "asan_test.cc"


	Jakub





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]