[Bug sanitizer/55518] New: boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[Bug sanitizer/55518] New: boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

             Bug #: 55518
           Summary: boehm-gc, libatomic, libffi and libgomp testsuite
                    can't find path to libasan for make check with
                    -fsanitizer
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu
                CC: dodji@gcc.gnu.org, dvyukov@gcc.gnu.org,
                    jakub@gcc.gnu.org, kcc@gcc.gnu.org


While using...

make -k check RUNTESTFLAGS="--target_board=unix'{-fsanitize=address}'"

is sufficient for the testsuite residing in the gcc subdirectory to find
the built libasan for linkage, the libffi testsuite fails in its entirety
with errors...

ld: library not found for -lasan^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
ld: library not found for -lasan^M
collect2: error: ld returned 1 exit status^M

The same issue exists in the libgomp, boehm-gc and libatomic testsuites.
Interestingly, the libstdc++-v3 manages to find the path to libasan without any
additional options being passed on --target_board=unix than -fsanitize=address.

[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-28 15:45:30 UTC ---
That is not a bug, you've requested to add that flag, therefore you are
responsible to make sure gcc finds it at link time and runtime (e.g. by
installing it temporarily into a system directory where it is found by default,
into sysroot, or using env var options to point it there.

That is the same thing as if you tried to use -fopenmp or -fgnu-tm options by
default.

[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-11-28 16:48:55 UTC ---
This seems to be sufficient for libstc++-v3...

Index: libstdc++-v3/testsuite/lib/libstdc++.exp
===================================================================
--- libstdc++-v3/testsuite/lib/libstdc++.exp    (revision 193849)
+++ libstdc++-v3/testsuite/lib/libstdc++.exp    (working copy)
@@ -84,7 +84,7 @@
 # Called once, during runtest.exp setup.
 proc libstdc++_init { testfile } {
     global env
-    global v3-sharedlib v3-libgomp
+    global v3-sharedlib v3-libgomp v3-libasan
     global srcdir blddir objdir tool_root_dir
     global cc cxx cxxflags cxxpchflags cxxldflags
     global includes
@@ -159,6 +159,18 @@
     }
     v3track libgompdir 3

+    # Locate libasan. This is only required for parallel mode.
+    set v3-libasan 0
+    set libasandir [lookfor_file $blddir/../libsanitizer/asan
.libs/libasan.$shlib_ext]
+    if {$libasandir != ""} {
+        set v3-libasan 1
+        set libasandir [file dirname $libasandir]
+        append ld_library_path_tmp ":${libasandir}"
+        verbose -log "libasan support detected"
+    }
+    v3track libasandir 3
+
+
     # Locate libstdc++ shared library. (ie libstdc++.so.)
     set v3-sharedlib 0
     set sharedlibdir [lookfor_file $blddir src/.libs/libstdc++.$shlib_ext]

[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |
           Severity|normal                      |enhancement

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-11-28 17:17:33 UTC ---
Switching to an enhancement of the testsuite coverage.

[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-28 17:23:32 UTC ---
I still think it is a very bad idea.  As I said earlier, there are lots of
similar compiler options that require their corresponding runtime libraries,
and adding lots of junk to each *.exp just because user might use those options
in RUNTESTFLAGS is overkill.

[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-11-28 18:23:45 UTC ---
Considering that H.J. is working towards a --with-build-config=bootstrap-asan
option, it would seem wise to allow for testing the existing FSF gcc testsuite
against libasan without folks having to really hack up their source tree to do
so. Wasn't libsanitizer added to vet the code generation of FSF gcc? That would
place it in a slightly different category than say --fopenmp or -fgnu-tm.

[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-11-28 20:18:00 UTC ---
Jakub, I've reposted the current results on x86_64-apple-darwin12 for...

make -k check RUNTESTFLAGS="--target_board=unix'{-fsanitize=address}'"

with manual adjustments to the build so that libasan is always found. 

http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg02388.html

Ignore the objc and obj-c++ issues which are related to pre-existing linker
problems in those libs. There are a huge number of failures in the g++ and
libstdc++-v3 testsuite triggered by the use of  fsanitize=address that merit
examination. The g++ and libstdc++-v3 failures almost all appear to be either
involving ASAN:SIGSEGV (some with many instances with a single failure) or
segfaults with no output from libasan as all.

[Bug sanitizer/55518] boehm-gc, libatomic, libffi and libgomp testsuite can't find path to libasan for make check with -fsanitizer

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55518

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-11-28 21:02:32 UTC ---
I meant many instances in a single g=+/libstdc++-v3  testsuite failure showing
mulitple instances of  ASAN:SIGSEGV.