[Bug sanitizer/57316] New: [4.8 regresion] build failure in libsanitizer

[Bug sanitizer/57316] New: [4.8 regresion] build failure in libsanitizer

[PHHargrove at lbl dot gov]

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

            Bug ID: 57316
           Summary: [4.8 regresion] build failure in libsanitizer
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: PHHargrove at lbl dot gov
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

On the same system where I reported bug 55989, I am now experiencing a build
failure in libsanitizer in the released 4.8.0.  As with that earlier bug,
libsanitizer is trying to use something low-level from Linux that did not exist
in older kernel versions.  In this case the "exit_group" systemcall.

I believe a colleague has seen the same problem in 4.8.1 snapshots.

-Paul

libtool: compile:  /home/pcp1/phargrov/data1/GCC/gcc-4.8.0/BLD/./gcc/xgcc
-shared-libgcc -B/home/pcp1/phargrov/data1/GCC/gcc-4.8.0/BLD/./gcc -nostdinc++
-L/home/pcp1/phargrov/data1/GCC/gcc-4.8.0/BLD/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/pcp1/phargrov/data1/GCC/gcc-4.8.0/BLD/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../libsanitizer/sanitizer_common -I ../../../../libsanitizer/include
-Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/i686-pc-linux-gnu
-I../../../../libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -MT
sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc  -fPIC -DPIC -o
.libs/sanitizer_linux.o
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 'void
__sanitizer::internal__exit(int)':
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11: error:
'__NR_exit_group' was not declared in this scope
   syscall(__NR_exit_group, exitcode);
           ^
make[4]: *** [sanitizer_linux.lo] Error 1

[Bug sanitizer/57316] [4.8 regresion] build failure in libsanitizer

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you don't have __NR_exit_group, your kernel very likely doesn't have the
rest of NPTL support either (so e.g. __NR_futex), so I'm surprised this is the
only error.

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[PHHargrove at lbl dot gov]

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

--- Comment #3 from Paul H. Hargrove <PHHargrove at lbl dot gov> ---
(In reply to Kostya Serebryany from comment #1)
> Sorry for the breakages, but we are unable to monitor build failures on old
> kernels unless someone sets up a regular testing (build bot) with such kernels
> for upstream code.

This error is from a private "build bot" I've now got set up to perform daily
builds of the gupc branch in SVN (see http://gcc.gnu.org/projects/gupc.html). 
As changes are merged from the trunk to that branch I will notice any build
failures and I report them to the GCC Bugzilla if/when I can reproduce them in
the trunk or recent snapshot (eg bug 55989) or in a release (as with this bug).
 Otherwise they are reported to the GUPC team.

I am configuring with --disable-libsanitizer right now, but will remove that
when/if this bug is resolved such that I can build again.


(In reply to Jakub Jelinek from comment #2)
> If you don't have __NR_exit_group, your kernel very likely doesn't have the
> rest of NPTL support either (so e.g. __NR_futex), so I'm surprised this is
> the only error.

This is an old Red Hat "2.4.21-60.ELsmp" kernel that contains various bits that
Red Hat backported.  So, the unistd.h has __NR_fuxtex but not __NR_exit_group. 
I can't say for sure that futex works, however, as there is no NPTL version of
libpthread on the system.

For my own purposes, there is no need to make libsanitizer work on this
platform.  So, if that is not possible I'd like to see configure probe for each
of the syscall numbers (and prctl constants as in bug 55989) and then
automatically disable building the sanitizer code if any are missing.  I don't
like current the build-is-broken-by-default situation.

[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

[rguenth at gcc dot gnu.org]

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

[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

[jakub at gcc dot gnu.org]

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

[skunk at iskunk dot org]

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

[jakub at gcc dot gnu.org]

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.2                       |4.8.3

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.2 has been released.

[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

[rguenth at gcc dot gnu.org]

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

[skunk at iskunk dot org]

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

[rguenth at gcc dot gnu.org]

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

[y.gribov at samsung dot com]

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=31916&action=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

[jakub at gcc dot gnu.org]

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

[y.gribov at samsung dot com]

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=31917&action=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

[jakub at gcc dot gnu.org]

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

[y.gribov at samsung dot com]

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=31921&action=edit
Third try

Makes sense, patch updated.

[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

[jakub at gcc dot gnu.org]

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

[y.gribov at samsung dot com]

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

[y.gribov at samsung dot com]

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 regression] build failure in libsanitizer

[PHHargrove at lbl dot gov]

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

--- Comment #20 from Paul H. Hargrove <PHHargrove at lbl dot gov> ---
(In reply to Yury Gribov from comment #19)
> Paul, could you check if libsanitizer is now auto-disabled on your system
> and close the bug in that case?

Probably can't get to this until next week.
However, I've added this to my TODO list.

-Paul

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[PHHargrove at lbl dot gov]

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

--- Comment #21 from Paul H. Hargrove <PHHargrove at lbl dot gov> ---
A build from svn trunk (r207062) completed w/o problems.
I see:
   Configuring in i686-pc-linux-gnu/libsanitizer
followed later by
   checking for necessary platform features... no

So the added configure check appears to have functioned as intended.

Do I need to test other branches too?

-Paul

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[y.gribov at samsung dot com]

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

--- Comment #22 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Paul H. Hargrove from comment #21)
> Do I need to test other branches too?

No, I don't think so.

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[y.gribov at samsung dot com]

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

--- Comment #23 from Yury Gribov <y.gribov at samsung dot com> ---
Can we close this one?

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[rguenth at gcc dot gnu.org]

https://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.3                       |4.8.4

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #25 from Yury Gribov <y.gribov at samsung dot com> ---
Can we close this?

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[PHHargrove at lbl dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #26 from Paul H. Hargrove <PHHargrove at lbl dot gov> ---
(In reply to Yury Gribov from comment #25)
> Can we close this?

Just tried to build the released 4.8.3 and still see the original problem (see
error messages below).  Same is true at the tip of the gcc-4_8-branch in svn
(at r216525).

However, 4.9.1 is fine.

So, please don't close if 4.8.x is still open to bug fixes.
If 4.8. is closed, then this bug can be closed too.

-Paul


libtool: compile:  /home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/./gcc/xgcc
-shared-libgcc -B/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/./gcc -nostdinc++
-L/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libstdc++-v3/src
-L/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../libsanitizer/sanitizer_common -I ../../../../libsanitizer/include
-Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/i686-pc-linux-gnu
-I../../../../libsanitizer/../libstdc++-v3/libsupc++ -g -O0 -D_GNU_SOURCE -MT
sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc  -fPIC -DPIC -o
.libs/sanitizer_linux.o
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function 'void
__sanitizer::internal__exit(int)':
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11: error:
'__NR_exit_group' was not declared in this scope
   syscall(__NR_exit_group, exitcode);
           ^
make[4]: *** [sanitizer_linux.lo] Error 1
make[4]: Leaving directory
`/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libsanitizer/sanitizer_common'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD/i686-pc-linux-gnu/libsanitizer'
make[2]: *** [all-stage1-target-libsanitizer] Error 2
make[2]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/pcp1/phargrov/tmp/gcc-4.8.3/BLD'
make: *** [all] Error 2

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[skunk at iskunk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #27 from Daniel Richard G. <skunk at iskunk dot org> ---
Likewise confirmed on the same Woody system from comment #5: 4.9.1 bootstraps
fine, 4.8.3 still has the bug.

(Oddly enough, the first configure run in the 4.9.1 bootstrap has the message
"checking for libsanitizer support... yes")

Given the target milestone, I presume there's going to be a 4.8.4?

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[y.gribov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

--- Comment #28 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to Paul H. Hargrove from comment #26)
> (In reply to Yury Gribov from comment #25)
> > Can we close this?
> 
> Just tried to build the released 4.8.3 and still see the original problem
> (see error messages below).  Same is true at the tip of the gcc-4_8-branch
> in svn (at r216525).
> 
> However, 4.9.1 is fine.

Right, I fixed this in 4.9 and never bothered to backport to 4.8.

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[jakub at gcc dot gnu.org]

https://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.4                       |4.8.5

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.8.5                       |4.9.0
      Known to fail|                            |4.8.5

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.9.0.