[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #18 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Thu Jan 23 14:32:05 2014 New Revision: 206966 URL: http://gcc.gnu.org/viewcvs?rev=206966root=gccview=rev Log: 2014-01-23 Yury Gribov y.gri...@samsung.com Jakub Jelinek ja...@redhat.com PR sanitizer/57316 * configure.ac: Check for missing syscalls. * Makefile.am: Likewise. * configure: Regenerate. * Makefile.in: Regenerate. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/Makefile.am trunk/libsanitizer/Makefile.in trunk/libsanitizer/configure trunk/libsanitizer/configure.ac
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #19 from Yury Gribov y.gribov at samsung dot com --- Paul, could you check if libsanitizer is now auto-disabled on your system and close the bug in that case?
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #11 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31916 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31916action=edit More robust check Does this look reasonable? Should also work for cross-builds.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Yury Gribov from comment #11) Created attachment 31916 [details] More robust check Does this look reasonable? Should also work for cross-builds. 1) these syscalls are only needed on Linux, not on Darwin I think, so you change would disable libsanitizer on Darwin (not that I care about it) 2) I think it is undesirable to put this check into toplevel configure, I'd say the determination when to make the whole libsanitizer UNSUPPORTED should be limited to target triplet checking. I think my preference would be to test this in libsanitizer/configure* and just make even the asan etc. conditional on an automake conditional.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Attachment #31916|0 |1 is obsolete|| --- Comment #13 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31917 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31917action=edit Second try (In reply to Jakub Jelinek from comment #12) 1) these syscalls are only needed on Linux, not on Darwin I think, so you change would disable libsanitizer on Darwin (not that I care about it) Fixed. 2) I think it is undesirable to put this check into toplevel configure I'd say the determination when to make the whole libsanitizer UNSUPPORTED should be limited to target triplet checking. I see. I think my preference would be to test this in libsanitizer/configure* and just make even the asan etc. conditional on an automake conditional. Makes sense. Something like this then?
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- I wouldn't call the conditional SYSCALL_SUPPORTED, but SANITIZER_SUPPORTED or so. In the future, the configure could have various other reasons why it should give up on building any sanitizer libraries altogether. Also, supposedly __NR_gettid could be added to the test too.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Attachment #31917|0 |1 is obsolete|| --- Comment #15 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31921 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31921action=edit Third try Makes sense, patch updated.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Sorry for not catching it earlier, I'm worried about -Wunused complaining about the vars. Can you instead use something like int x = syscall (__NR_gettid); syscall (__NR_futex, x, 1, 1); syscall (__NR_exit_group, 0); ? Please post to gcc-patches with the change (if it works). Thanks.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #17 from Yury Gribov y.gribov at samsung dot com --- Will do.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|WAITING |NEW
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-10-30 Ever confirmed|0 |1 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- What's the status of this bug?
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #10 from Daniel Richard G. skunk at iskunk dot org --- (In reply to Richard Biener from comment #9) What's the status of this bug? Same as I reported in comment #5---I just confirmed with a build of 4.8.2.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #6 from Kostya Serebryany kcc at gcc dot gnu.org ---
Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
pthread_mutex_*() be sensible here?
That would be non-trivial. We intercept the pthread_ functions so we can't
call them directly. We'll at least need to bypass our own interceptors.
And as I mentioned before, older kernels will likely not work anyway for
a few other reasons.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #7 from Daniel Richard G. skunk at iskunk dot org --- Created attachment 30723 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30723action=edit Trivial configure-time check (In reply to Kostya Serebryany from comment #6) That would be non-trivial. We intercept the pthread_ functions so we can't call them directly. We'll at least need to bypass our own interceptors. And as I mentioned before, older kernels will likely not work anyway for a few other reasons. Okay, so I guess there's no alternative but to disable libsanitizer for these systems. I see that libsanitizer support is inferred automatically by the libsanitizer/configure.tgt script, which is sourced from the top-level configure script. This script is not processed by Autoconf, so doing a test-compile in there would be somewhat awkward. However, on this old Debian system, the linux/futex.h header doesn't exist at all, so picking up on that would be enough for me. See attached patch for a first-draft proposal. (There probably needs to be some build/host/target-sysroot awareness of where to look for the header; I'm not familiar enough with building cross-compilers.)
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
Daniel Richard G. skunk at iskunk dot org changed:
What|Removed |Added
CC||skunk at iskunk dot org
--- Comment #5 from Daniel Richard G. skunk at iskunk dot org ---
I get this same error building on an old Debian woody system:
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
function 'void __sanitizer::internal__exit(int)':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11:
error: '__NR_exit_group' was not declared in this scope
syscall(__NR_exit_group, exitcode);
^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Lock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:529:13:
error: '__NR_futex' was not declared in this scope
syscall(__NR_futex, m, FUTEX_WAIT, MtxSleeping, 0, 0, 0);
^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Unlock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:537:13:
error: '__NR_futex' was not declared in this scope
syscall(__NR_futex, m, FUTEX_WAKE, 1, 0, 0, 0);
^
gmake[4]: *** [sanitizer_linux.lo] Error 1
Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
pthread_mutex_*() be sensible here?
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.1 |4.8.2 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 4.8.1 has been released.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.1 Summary|[4.8 regression] build |[4.8/4.9 regression] build |failure in libsanitizer |failure in libsanitizer
