https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Jakub Jelinek changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #14 from Jakub Jelinek ---
Another option is executable testcase trying to dlsym __tls_get_addr_internal
(but that is not cross-compilation friendly), or perhaps nm or readelf on the
dynamic linker (but that is not really that easy fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #13 from Dominik Vogt ---
The opinion of whoever added the S390 code to sanitizer_common_interceptors.inc
("chefmax") might help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #12 from Dominik Vogt ---
> so it should then for s390*-*-linux* also test for glibc >= 2.19 using
> AC_TRY_COMPILE and preprocessor macros or so?
Or something like
$ nm /lib/ld-*.*.so | grep __tls_get_addr_internal
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #11 from Dominik Vogt ---
Hm, Stefan says that RHEL 7.3 has a Glibc-2.17 with a backport of the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #10 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #9)
Perhaps say:
AC_TRY_COMPILE([#include ],[
syscall (__NR_gettid);
syscall (__NR_futex);
syscall (__NR_exit_group);
+#if (defined(__s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #9 from Jakub Jelinek ---
gcc/configure.ac has:
# Determine the version of glibc, if any, used on the target.
AC_MSG_CHECKING([for target glibc version])
AC_ARG_WITH([glibc-version],
[AS_HELP_STRING([--with-glibc-version=M.N],
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #8 from Dominik Vogt ---
The symbol was introduced to Glibc after 2.18 and before 2.19.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #7 from Jakub Jelinek ---
Ah, that might explain this, I've been using glibc 2.25 prerelease during
testing.
The glibc change has been a fix for
https://sourceware.org/bugzilla/show_bug.cgi?id=16214
I don't know the s390{,x} TLS good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #6 from Andreas Krebbel ---
I don't think modifying libsanitizer to support older Glibcs is required. The
only change we might want to consider is adding a configure check to
libsanitizer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #5 from Dominik Vogt ---
Okay, the symbol __tls_get_addr_internal exists since Glibc-2.19 on s390*, and
the test machine has Glibc-2.18. Is this something that needs to be fixed in
libsanitizer, or does the test machine need an upgra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #4 from Dominik Vogt ---
From /sysdeps/s390/dl-tls.h:
/* The special thing about the s390 TLS ABI is that we do not have the
standard __tls_get_addr function but the __tls_get_offset function
which differs in two important aspe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #3 from Dominik Vogt ---
For example, use-after-scope-goto-1.c built with -O0 -m31 crashed during exit:
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) up
#1 0x77a65c0a in __interceptor___tls_get_addr_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #2 from Dominik Vogt ---
No, that does not help.
Meanwhile the Tests on s390x have completed (r244119), and there are > 100 Asan
related FAILs with -m31 as well as -m64. Not anywhere near your or Andreas'
test results. Many FAILs s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #1 from Jakub Jelinek ---
Can you:
s390*-*-linux*)
-if test x$ac_cv_sizeof_void_p = x4; then
-UNSUPPORTED=1
-fi
in libsanitizer/configure.tgt and retry? As I said on the mailing list, I
don't have a
16 matches
Mail list logo
