Your message dated Wed, 11 Jun 2014 22:50:44 +0200
with message-id <[email protected]>
and subject line Bug#751026: systemtap-sdt-dev: breaks eglibc build on alpha
failure and testsuite failures.
has caused the Debian Bug report #751026,
regarding systemtap-sdt-dev: breaks eglibc build on alpha
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
751026: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751026
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: eglibc
Version: 2.19-1
Severity: important
User: [email protected]
Usertags: alpha
Justification: fails to build from source but built in the past
X-Debbugs-CC: [email protected]
eglibc FTBFS on alpha for two reasons, firstly, due to the inclusion of
systemtap headers and, secondly, because of what might be broken
FUTEX_CLOCK_REALTIME support in the kernel.
The systemtap header inclusion introduces an invalid unsplit symbol
reference to global_max_fast in inline asm leading to a failure to compile
malloc/malloc.c, which is the reason for the compiler ICE seen in the build
log at:
http://buildd.debian-ports.org/status/fetch.php?pkg=eglibc&arch=alpha&ver=2.19-1&stamp=1401942698
The compiler ICE is now fixed in gcc upstream (PR target/61336) to a
graceful error exit which won't help us in getting eglibc built on alpha.
So my question: can we have the systemtap-sdt-dev build-dep removed from
eglibc for a build on Alpha? (And what are the implications of that?
Presumably nothing since even a number of official arches are not supported
by systemtap?)
With the systemtap headers removed the build gets to the test-suite with
ominous looking failures in tst-rwlock6, tst-rwlock11, tst-rwlock12, etc.
The assumption __ASSUME_FUTEX_CLOCK_REALTIME activated at kernel version
2.6.29 in the eglibc source would appear to be false for Alpha, or maybe the
test suite failures are due to a broken kernel (I tested with kernels 3.10.x
and 3.14.x and the build daemon is still on 3.13.x; all fail). Whatever,
undefining __ASSUME_FUTEX_CLOCK_REALTIME results in correct behaviour for
the rwlock tests. I attach a patch for that.
For a successful test build (with a 3.10.x kernel) I used in
debian/testsuite-checking/expected-results-alpha-linux-gnu-libc (and also
for the alphaev67 variant libc) the following:
annexc.out, Error 1 (ignored)
badsalttest.out, Error 1
run-conformtest.out, Error 1 (ignored)
test-double.out, Error 1
test-float.out, Error 1
test-snan.out, Error 1
tst-backtrace2.out, Error 1
tst-backtrace3.out, Error 1
tst-backtrace4.out, Error 1
tst-backtrace5.out, Error 1
tst-backtrace6.out, Error 1
tst-cancelx17.out, Error 1
tst-cpuclock2.out, Error 1
tst-eintr1.out, Error 1
tst-mqueue5.out, Error 1
tst-ptrguard1.o, Error 1
tst-stackguard1-static.o, Error 1
tst-stackguard1.o, Error 1
tst-timer.out, Error 139
tst-waitid.out, Error 1
tst-writev.out, Error 1
tst-cputimer1.out, Error 1
In the libc build the test suite failures were
annexc.out, Error 1 (ignored)
badsalttest.out, Error 1
run-conformtest.out, Error 1 (ignored)
test-double.out, Error 1
test-float.out, Error 1
test-snan.out, Error 1
tst-backtrace2.out, Error 1
tst-backtrace3.out, Error 1
tst-backtrace4.out, Error 1
tst-backtrace5.out, Error 1
tst-backtrace6.out, Error 1
tst-eintr1.out, Error 1
tst-ptrguard1.o, Error 1
tst-stackguard1-static.o, Error 1
tst-stackguard1.o, Error 1
and the encountered progressions were:
tst-cancelx17.out, Error 1
tst-cpuclock2.out, Error 1
tst-cputimer1.out, Error 1
tst-mqueue5.out, Error 1
tst-timer.out, Error 139
tst-waitid.out, Error 1
tst-writev.out, Error 1
In the alphaev67 build the test suite failures were:
annexc.out, Error 1 (ignored)
tst-ptrguard1.o, Error 1
tst-stackguard1-static.o, Error 1
tst-stackguard1.o, Error 1
so the encountered progressions were:
badsalttest.out, Error 1
run-conformtest.out, Error 1 (ignored)
test-double.out, Error 1
test-float.out, Error 1
test-snan.out, Error 1
tst-backtrace2.out, Error 1
tst-backtrace3.out, Error 1
tst-backtrace4.out, Error 1
tst-backtrace5.out, Error 1
tst-backtrace6.out, Error 1
tst-cancelx17.out, Error 1
tst-cpuclock2.out, Error 1
tst-cputimer1.out, Error 1
tst-eintr1.out, Error 1
tst-mqueue5.out, Error 1
tst-timer.out, Error 139
tst-waitid.out, Error 1
tst-writev.out, Error 1
It would seem that the alphaev67 library build leads to a much more robust
library.
Cheers
Michael.
Index: eglibc-2.19/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h
===================================================================
--- eglibc-2.19.orig/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h
+++ eglibc-2.19/ports/sysdeps/unix/sysv/linux/alpha/kernel-features.h
@@ -93,4 +93,7 @@
# define __ASSUME_FDATASYNC 1
#endif
+/* Appears to have never worked on Alpha. */
+#undef __ASSUME_FUTEX_CLOCK_REALTIME
+
#endif /* _KERNEL_FEATURES_H */
--- End Message ---
--- Begin Message ---
On Wed, Jun 11, 2014 at 08:55:42PM +1200, Michael Cree wrote:
> On Tue, Jun 10, 2014 at 10:08:24PM +0200, Aurelien Jarno wrote:
> > On Tue, Jun 10, 2014 at 09:45:30PM +0200, Mark Wielaard wrote:
> > > On Tue, 2014-06-10 at 21:25 +0200, Aurelien Jarno wrote:
> > > > | Note that the asm in question comes from system tap, which has not
> > > > been
> > > > | ported to alpha. So you're probably better off disabling that in your
> > > > | (e)glibc build too.
> > >
> > > I asked Richard and he said that mainline GCC now allows the "i"
> > > constraint with a symbol, with an asm. So it shouldn't produce an error.
> > > What error are you seeing?
> > >
> > > stap might not know how to interpret such SDT ELF notes. Since systemtap
> > > is not known to work on alpha (I don't know for other SDT consumers like
> > > gdb and perf). But that would be independent of building with sys/sdt.h.
> > > So unless I misunderstood him things should compile fine, even if you
> > > decided to keep sys/sdt.h enabled for the glibc build on alpha.
> > >
> > > Of course, if none of the SDT consumers are known to work on alpha then
> > > having them might just be a noop and it should also be fine to disable
> > > them on that platform if you wish. But I don't think that is necessary.
> >
> > I don't have access to an alpha machine. Michael, could you please
> > confirm that the patch from PR61336 does remove the ICE, but in addition
> > allow the file to be compiled?
>
> I found a moment earlier today to schedule a gcc build with the patch from
> PR61336 and that has completed.
>
> The file (preprocessed source of malloc/malloc.c from glibc with systemtap
> headers included) which I have just reconfirmed generates an ICE with
> gcc-4.8.3-2 like so:
>
> gcc-4.8 /tmp/ccDghSDC.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline
> -Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe
> -Wstrict-prototypes -mlong-double-128 -mieee -mfp-rounding-mode=d -fpic
> malloc.c: In function ‘__libc_mallopt’:
> malloc.c:4830:1: internal compiler error: in print_operand_address, at
> config/alpha/alpha.c:5454
>
>
> now successfully compiles with gcc with the patch from PR61336, like so:
>
>
> /home/mjc/toolchain/gcc-build/./gcc/xgcc
> -B/home/mjc/toolchain/gcc-build/./gcc/ /tmp/ccDghSDC.c -c -std=gnu99
> -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants
> -frounding-math -g -pipe -Wstrict-prototypes -mlong-double-128 -mieee
> -mfp-rounding-mode=d -fpic
> In file included from malloc.c:1875:0:
> arena.c: In function ‘ptmalloc_unlock_all2’:
> arena.c:303:33: warning: right-hand operand of comma expression has no effect
> [-Wunused-value]
> arena.c:313:25: warning: right-hand operand of comma expression has no effect
> [-Wunused-value]
> In file included from malloc.c:1875:0:
> arena.c: In function ‘_int_new_arena’:
> arena.c:768:24: warning: right-hand operand of comma expression has no effect
> [-Wunused-value]
>
>
> Seems I misunderstood RTH's commit comment; I saw the "Use
> output_operand_lossage" bit and thought it meant that it would error out,
> but now looking at the patch I see that is only for the default case of
> the switch, not the bit handling the operand of the inline asm.
As the problem has been (or is about to in the Debian case) fixed at
the GCC level, I am now closing the bug opened against
systemtap-sdt-dev.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
[email protected] http://www.aurel32.net
--- End Message ---
