GNU Hurd/ open issues/ glibc

Welcome to... ... the GNU Hurd!

Here's what's to be done for maintaining glibc.

  1. General information
  2. Sources
  3. Debian Cheat Sheet
  4. Configuration
    1. Update
  5. Build
    1. Analysis
  6. Install
    1. Analysis
  7. Testsuite
    1. Analysis

General information

Sources

Debian Cheat Sheet

Configuration

Last reviewed up to the Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 (2012-11-03) sources.

  • t/hurdsig-fixes

    hurdsig.c: In function '_hurd_internal_post_signal':
hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
hurdsig.c:1168:12: note: 'pending' was declared here

  • t/host-independency

    id:"87bougerfb.fsf@kepler.schwinge.homeip.net", id:"20120525202732.GA31088@intel.com", commit 918b56067a444572f1c71b02f18255ae4540b043. [[!GCC_PR 53183]], GCC commit c05436a7e361b8040ee899266e15bea817212c37.

  • t/pie-sbrk

    PIE.

  • t/sysvshm

    ../sysdeps/mach/hurd/shmat.c: In function '__shmat':
../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]
../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive':
../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable]
../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized]
../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized]

  • t/tls

  • t/tls-threadvar

  • t/verify.h

    People didn't like this too much.

    Other examples:

    • 11988f8f9656042c3dfd9002ac85dff33173b9bd -- static_assert

  • cross-gnu, without --disable-multi-arch

    i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...]
../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages:
../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined
make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1
make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string'

    Might simply be a missing patch(es) from master.

  • --disable-multi-arch

    IRC, freenode, #hurd, 2012-11-22

    <pinotree> tschwinge: is your glibc build w/ or w/o multiarch?
<tschwinge> pinotree: See open_issues/glibc: --disable-multi-arch
<pinotree> ah, because you do cross-compilation?
<tschwinge> No, that's natively.
<tschwinge> There is also a not of what happened in cross-gnu when I
  enabled multi-arch.
<tschwinge> No idea whether that's still relevant, though.
<pinotree> EPARSE
<tschwinge> s%not%note
<tschwinge> Better?
<pinotree> yes :)
<tschwinge> As for native builds: I guess I just didn't (want to) play
  with it yet.
<pinotree> it is enabled in debian since quite some time, maybe other
  i386/i686 patches (done for linux) help us too
<tschwinge> I though we first needed some CPU identification
  infrastructe before it can really work?
<tschwinge> I thought [...].
<pinotree> as in use the i686 variant as runtime automatically? i guess
  so
<tschwinge> I thought I had some notes about that, but can't currently
  find them.
<tschwinge> Ah, I probably have been thinking about open_issues/ifunc
  and open_issues/libc_variant_selection.

  • --build=X

    long double test: due to cross_compiling = maybe wants to execute a file, which fails. Thus --build=X has to be set.

  • Check what all these are:

    running configure fragment for sysdeps/mach/hurd
checking Hurd header version... ok
running configure fragment for sysdeps/mach
checking for i586-pc-gnu-mig... i586-pc-gnu-mig
checking for mach/mach_types.h... yes
checking for mach/mach_types.defs... yes
checking for task_t in mach/mach_types.h... task_t
checking for thread_t in mach/mach_types.h... thread_t
checking for creation_time in task_basic_info... yes
checking for mach/mach.defs... yes
checking for mach/mach4.defs... yes
checking for mach/clock.defs... no
checking for mach/clock_priv.defs... no
checking for mach/host_priv.defs... no
checking for mach/host_security.defs... no
checking for mach/ledger.defs... no
checking for mach/lock_set.defs... no
checking for mach/processor.defs... no
checking for mach/processor_set.defs... no
checking for mach/task.defs... no
checking for mach/thread_act.defs... no
checking for mach/vm_map.defs... no
checking for mach/memory_object.defs... yes
checking for mach/memory_object_default.defs... yes
checking for mach/default_pager.defs... yes
checking for mach/i386/mach_i386.defs... yes
checking for egrep... grep -E
checking for host_page_size in mach_host.defs... no
checking for mach/machine/ndr_def.h... no
checking for machine/ndr_def.h... no
checking for i386_io_perm_modify in mach_i386.defs... yes
checking for i386_set_gdt in mach_i386.defs... yes
checking whether i586-pc-gnu-mig supports the retcode keyword... yes

  • sysdeps/i386/stackguard-macros.h

    See t/tls.

  • Verify 77c84aeb81808c3109665949448dba59965c391e against ~/shared/glibc/make_TAGS.patch.

  • HP_SMALL_TIMING_AVAIL not defined anywhere.

  • Unify CPUCLOCK_WHICH stuff in clock_* files.

  • Not all tests are re-run in a make -k tests; make tests-clean; make -k tests cycle. For example, after make tests-clean:

    $ find ./ -name \*.out
./localedata/tst-locale.out
./localedata/sort-test.out
./localedata/de_DE.out
./localedata/en_US.out
./localedata/da_DK.out
./localedata/hr_HR.out
./localedata/sv_SE.out
./localedata/tr_TR.out
./localedata/fr_FR.out
./localedata/si_LK.out
./localedata/tst-mbswcs.out
./iconvdata/iconv-test.out
./iconvdata/tst-tables.out
./stdlib/isomac.out
./posix/wordexp-tst.out
./posix/annexc.out
./posix/tst-getconf.out
./elf/check-textrel.out
./elf/check-execstack.out
./elf/check-localplt.out
./c++-types-check.out
./check-local-headers.out
./begin-end-check.out

  • CPUCLOCK_WHICH, t/cpuclock

    /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime':
/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH'
/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH'
collect2: error: ld returned 1 exit status
make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1
make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt'
make[1]: *** [rt/others] Error 2
make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc'
make: *** [all] Error 2

  • Missing interfaces, amongst many more.

    Many more are missing, some of which have been announced in NEWS, others typically haven't (like new flags to existing functions). Typically, porters will notice missing functionaly. But in case you're looking for something to work on, here's a list.

    AT_EMPTY_PATH, CLOCK_BOOTTIME, CLOCK_BOOTTIME_ALARM, CLOCK_REALTIME_ALARM, O_PATH, PTRACE_* (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27, b1b2aaf8eb9eed301ea8f65b96844568ca017f8b), RLIMIT_RTTIME, SEEK_DATA (unistd.h), SEEK_HOLE (unistd.h) clock_adjtime, fallocate, fallocate64, name_to_handle_at, open_by_handle_at, process_vm_readv, process_vm_writev, sendmmsg, setns, sync_file_range, mremap and several MAP *

    Check also the content of gnu/stubs.h, which lists all the functions marked as stub which only return ENOSYS.

    • chflags

      Patch sent, id:"20120427012130.GZ19431@type.famille.thibault.fr".

      IRC, OFTC, #debian-hurd, 2012-04-27:

      <Steap> Does anyone have any idea why int main(void) { return
  chflags(); } will compile with gcc but not with g++ ? It says
  that "chflags" was not declared in this scope.
<Steap> I get the same error on FreeBSD, but including sys/stat.h
  makes it work
<Steap> Can't find a solution on Hurd though :/
<youpi> the Hurd doesn't have chflags
<youpi> apparently linux neither
<youpi> what does it do?
<Steap> change flags :)
<Steap> Are you sure the Hurd does not have chflags ? Because gcc
  does not complain
<youpi> there is no chflags function in /usr/include
<youpi> but what flags does it change?
<Steap> According to the FreeBSD manpage, it can set flags such as
  UF_NODUMP, UF_IMMUTABLE etc.
<youpi> Hum, there is actually a chflags() definition
<youpi> but no declaration
<youpi> so actually chflags is supported, but the declaration was
  forgotten
<youpi> probably because since linux doens't have it, it has never
  been a problem up to now
<youpi> so I'd say ignore the error for now, we'll add the
  declaration

    • getcontext/setcontext

    • futimesat

      If we have all of 'em (check Linux kernel), #define __ASSUME_ATFCTS.

    • bits/stat.h [__USE_ATFILE]: UTIME_NOW, UTIME_OMIT

    • io/fcntl.h [__USE_ATFILE]

      Do we support AT_FDCWD et al.? (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.)

    • t/opendirat: opendirat (scandirat, scandirat64)

      Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 + 14d96785125abee5e9a49a1c3037f35a581750bd.

    • madvise, MADV_DONTNEED, MADV_DONTDUMP, MADV_DODUMP

      glibc madvise vs static linking.

    • msync

      Then define _POSIX_MAPPED_FILES, _POSIX_SYNCHRONIZED_IO.

    • sys/epoll.h

      Used by wayland, for example.

    • sys/eventfd.h

    • sys/inotify.h

    • sys/signalfd.h

    • sys/timerfd.h

    • timespec_get (74033a2507841cf077e31221de2481ff30b43d51)

    • waitflags.h (WEXITED, WNOWAIT, WSTOPPED, WCONTINUED)

      IRC, freenode, #hurd, 2012-04-20:

      <pinotree> in glibc, we use the generic waitflags.h which, unlike
  linux's version, does not define WEXITED, WNOWAIT, WSTOPPED,
  WCONTINUED
<pinotree> should the generic bits/waitflags.h define them anyway,
  since they are posix?
<youpi> well, we'd have to implement them anyway
<youpi> but otherwise, I'd say yes
<pinotree> sure, but since glibc headers should expose at least
  everything declared by posix, i thought they should be defined
  anyway
<youpi> that might bring bugs
<youpi> some applications might be #ifdefing them
<youpi> and break when they are defined but not working
<pinotree> i guess they would define them to 0, andd having them to
  non-zero values shouldn't break them (since those values don't do
  anything, so they would act as if they were 0.. or not?)
<youpi> no, I mean they would do something else, not define them to
  0
<pinotree> like posix/tst-waitid.c, you mean?
<youpi> yes

      See posix/tst-waitid.out failure below.

    • getconf things (see below the results of tst-getconf.out)

    • getsockopt, setsockopt

      IRC, freenode, #hurd, 2013-02-14

      <gnu_srs> Hi, {get,set}sockopt is not supported on Hurd. This shows
  e.g. in the gnulib's test-{poll,select} code.
<gnu_srs> Reading
  http://hea-www.harvard.edu/~fine/Tech/addrinuse.html there might
  be reasons _not_ to implement them, comments?
<pinotree> uh? they are supported on hurd
<gnu_srs> not  SO_REUSEPORT for setsockopt()
<pinotree> that isn't the same as claiming "get/setsockopt is not
  supported on hurd"
<pinotree> most probably that option is not implemented by the
  socket family you are using
<gnu_srs> OK, some options like  SO_REUSEPORT then, more info in
  the link.
<pinotree> note also SO_REUSEPORT is not posix
<pinotree> and i don't see SO_REUSEPORT mentioned in the page you
  linked
<gnu_srs> No, but SO_REUSEADDR

      IRC, freenode, #hurd, 2013-02-23

      <gnu_srs> as an example, the poll test code from gnulib fails due
  to that problem (and I've told you before)
<pinotree> gnu_srs: what's the actual failure?
<pinotree> can you provide a minimal test case showing the issue?
<gnu_srs> pinotree: A smaller test program:
  http://paste.debian.net/237495/
<pinotree> gnu_srs: setting SO_REUSEADDR before binding the socket
  works...
<pinotree> and it seems it was a bug in the gnulib tests, see
  http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6ed6dffbe79bcf95e2ed5593eee94ab32fcde3f4
<gnu_srs> pinotree: You are right, still the code I pasted pass on
  Linux, not on Hurd.
<pinotree> so?
<pinotree> the code is wrong
<pinotree> you cannot change what bind does after you have called
  it
* pinotree → out
<gnu_srs> so linux is buggy?
<braunr> no, linux is more permissive
<braunr> (at least, on this matter)

    For specific packages:

  • Create t/cleanup_kernel-features.h.

  • Add tests from Linux kernel commit messages for t/dup3 et al.

  • In sysdeps/unix/sysv/linux/Makefile, there are a bunch of -DHAVE_SENDFILE -- but we do have sendfile, too.

    Define __ASSUME_SENDFILE to 1 in kernel-features.h, if sendfile works.

  • /usr/include/pthread.h overwrite issue

    make, after editing nss/nss_db/db-initgroups.c:

    [...]
make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv'
make  subdir=nss -C nss ..=../ others
make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
/usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h
/usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied
make[2]: *** [/usr/include/pthread.h] Error 1
make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
make[1]: *** [nss/others] Error 2
make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker'
make: *** [all] Error 2

    See id:"871uv99c59.fsf@kepler.schwinge.homeip.net". Passing install_root=/INVALID to make/make check is a cheap cure. For make install, prepending an additional slash to install_root (that is, install_root=//[...]) is enough to obfuscate the Makefile rules.

  • sysdeps/unix/sysv/linux/syslog.c

  • fsync on a pipe

    IRC, freenode, #hurd, 2012-08-21:

    <braunr> pinotree: i think gnu_srs spotted a conformance problem in
  glibc
<pinotree> (only one?)
<braunr> pinotree: namely, fsync on a pipe (which is actually a
  socketpair) doesn't return EINVAL when the "operation not supported"
  error is returned as a "bad request message ID"
<braunr> pinotree: what do you think of this case ?
<pinotree> i'm far from an expert on such stuff, but seems a proper E*
  should be returned
<braunr> (there also is a problem in clisp falling in an infinite loop
  when trying to handle this, since it uses fsync inside the error
  handling code, eww, but we don't care :p)
<braunr> basically, here is what clisp does
<braunr> if fsync fails, and the error isn't EINVAL, let's report the
  error
<braunr> and reporting the error in turn writes something on the
  output/error stream, which in turn calls fsync again
<pinotree> smart
<braunr> after the stack is exhausted, clisp happily crashes
<braunr> gnu_srs: i'll alter the clisp code a bit so it knows about our
  mig specific error
<braunr> if that's the problem (which i strongly suspect), the solution
  will be to add an error conversion for fsync so that it returns
  EINVAL
<braunr> if pinotree is willing to do that, he'll be the only one
  suffering from the dangers of sending stuff to the glibc maintainers
  :p
<pinotree> that shouldn't be an issue i think, there are other glibc
  hurd implementations that do such checks
<gnu_srs> does fsync return EINVAL for other OSes?
<braunr>        EROFS, EINVAL
<braunr>               fd is bound to a special file which does not
  support synchronization.
<braunr> obviously, pipes and sockets don't
<pinotree>
  http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html
<braunr> so yes, other OSes do just that
<pinotree> now that you speak about it, it could be the failure that
  the gnulib fsync+fdatasync testcase have when being run with `make
  check` (although not when running as ./test-foo)
<braunr> hm we may not need change glibc
<braunr> clisp has a part where it defines a macro IS_EINVAL which is
  system specific
<braunr> (but we should change it in glibc for conformance anyway)
<braunr> #elif defined(UNIX_DARWIN) || defined(UNIX_FREEBSD) ||
  defined(UNIX_NETBSD) || defined(UNIX_OPENBSD) #define IS_EINVAL_EXTRA
  ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV))
<pinotree> i'd rather add nothing to clisp
<braunr> let's see what posix says
<braunr> EINVAL
<braunr> so right, we should simply convert it in glibc
<gnu_srs> man fsync mentions EINVAL
<braunr> man pages aren't posix, even if they are usually close
<gnu_srs> aha
<pinotree> i think checking for MIG_BAD_ID and EOPNOTSUPP (like other
  parts do) will b enough
<pinotree> *be
<braunr> gnu_srs: there, it finished correctly even when piped
<gnu_srs> I saw that, congrats!
<braunr> clisp is quite tricky to debug
<braunr> i never had to deal with a program that installs break points
  and handles segfaults itself in order to implement growing stacks :p
<braunr> i suppose most interpreters do that
<gnu_srs> So the permanent change will be in glibc, not clisp?
<braunr> yes

    IRC, freenode, #hurd, 2012-08-24:

    <gnu_srs1> pinotree: The changes needed for fsync.c is at
  http://paste.debian.net/185379/ if you want to try it out (confirmed
  with rbraun)
<youpi> I agree with the patch, posix indeed documents einval as the
  "proper"  error value
<pinotree> there's fdatasync too
<pinotree> other places use MIG_BAD_ID instead of EMIG_BAD_ID
<braunr> pinotree: i assume that if you're telling us, it's because
  they have different values
<pinotree> braunr: tbh i never seen the E version, and everywhere in
  glibc the non-E version is used
<gnu_srs1> in sysdeps/mach/hurd/bits/errno.h only the E version is
  defined
<pinotree> look in gnumach/include/mach/mig_errors.h
<pinotree> (as the comment in errno.h say)
<gnu_srs1> mig_errors.h yes. Which comment: from errors.h: /* Errors
  from <mach/mig_errors.h>.  */ and then the EMIG_ stuff?
<gnu_srs1> Which one is used when building libc?
<gnu_srs1> Answer: At least in fsync.c errno.h is used: #include
  <errno.h>
<gnu_srs1> Yes, fdatasync.c should be patched too.
<gnu_srs1> pinotree: You are right: EMIG_ or MIG_ is confusing. 
<gnu_srs1> /usr/include/i386-gnu/bits/errno.h:     /* Errors from
  <mach/mig_errors.h>.  */
<gnu_srs1> /usr/include/hurd.h:#include <mach/mig_errors.h>

    IRC, freenode, #hurd, 2012-09-02:

    <antrik> braunr: regarding fsync(), I agree that EOPNOTSUPP probably
  should be translated to EINVAL, if that's what POSIX says. it does
  *not* sound right to translate MIG_BAD_ID though. the server should
  explicitly return EOPNOTSUPP, and that's what the default trivfs stub
  does. if you actually do see MIG_BAD_ID, there must be some other
  bug...
<braunr> antrik: right, pflocal doesn't call the trivfs stub for socket
  objects
<braunr> trivfs_demuxer is only called by the pflocal node demuxer, for
  socket objects it's another call, and i don't think it's the right
  thing to call trivfs_demuxer there either
<pinotree> handling MAG_BAD_ID isn't a bad idea anyway, you never know
  what the underlying server actually implements
<pinotree> (imho)
<braunr> for me, a bad id is the same as a not supported operation
<pinotree> ditto
<pinotree> from fsync's POV, both the results are the same anyway, ie
  that the server does not support a file_sync operation
<antrik> no, a bad ID means the server doesn't implement the protocol
  (or not properly at least)
<antrik> it's usually a bug IMHO
<antrik> there is a reason we have EOPNOTSUPP for operations that are
  part of a protocol but not implemented by a particular server
<pinotree> antrik: even if it could be the case, there's no reason to
  make fsync fail anyway
<antrik> pinotree: I think there is. it indicates a bug, which should
  not be hidden
<pinotree> well, patches welcome then...
<antrik> thing is, if sock objects are actually not supposed to
  implement the file interface, glibc shouldn't even *try* to call
  fsync on them
<pinotree> how?
<pinotree> i mean, can you check whether the file interface is not
  implemented, without doing a roundtrip^
<pinotree> ?
<antrik> well, the sock objects are not files, i.e. they were *not*
  obtained by file_name_lookup(), but rather a specific call. so glibc
  actually *knows* that they are not files.
<braunr> antrik: this way of thinking means we need an "fd" protocol
<braunr> so that objects accessed through a file descriptor implement
  all fd calls
<antrik> now I wonder though whether there are conceivable use cases
  where it would make sense for objects obtained through the socket
  call to optionally implement the file interface...
<antrik> which could actually make sense, if libc lets through other
  file calls as well (which I guess it does, if the sock ports are
  wrapped in normal fd structures?)
<braunr> antrik: they are
<braunr> and i'd personally be in favor of such an fd protocol, even if
  it means implementing stubs for many useless calls
<braunr> but the way things are now suggest a bad id really means an
  operation is simply not supported
<antrik> the question in this case is whether we should make the file
  protocol mandatory for anything that can end up in an FD; or whether
  we should keep it optional, and add the MIG_BAD_ID calls to *all* FD
  operations
<antrik> (there is no reason for fsync to be special in this regard)
<braunr> yes
<antrik> braunr: BTW, I'm rather undecided whether the right approach
  is a) requiring an FD interface collection, b) always checking
  MIG_BAD_ID, or perhaps c) think about introducing a mechanism to
  explicitly query supported interfaces...

    IRC, freenode, #hurd, 2012-09-03:

    <braunr> antrik: querying interfaces sounds like an additional penalty
  on performance
<antrik> braunr: the query usually has to be done only once. in fact it
  could be integrated into the name lookup...
<braunr> antrik: once for every object
<braunr> antrik: yes, along with the lookup would be a nice thing

    id:"1351231423.8019.19.camel@hp.my.own.domain".

  • t/no-hp-timing

    IRC, freenode, #hurd, 2012-11-16

    <pinotree> tschwinge: wrt the glibc topgit branch t/no-hp-timing,
  couldn't that file be just replaced by #include
  <sysdeps/generic/hp-timing.h>?

  • flockfile/ftrylockfile/funlockfile

    IRC, freenode, #hurd, 2012-11-16

    <pinotree> youpi: uhm, in glibc we use
  stdio-common/f{,try,un}lockfile.c, which do nothing (as opposed to eg
  the nptl versions, which do lock/trylock/unlock); do you know more
  about them?
<youpi> pinotree: ouch
<youpi> no, I don't know
<youpi> well, I do know what they're supposed to do
<pinotree> i'm trying fillig them, let's see
<youpi> but not why we don't have them
<youpi> (except that libpthread is "recent")
<youpi> yet another reason to build libpthread in glibc, btw
<youpi> oh, but we do provide lockfile in libpthread, don't we ?
<youpi> pinotree: yes, and libc has weak variants, so the libpthread
  will take over
<pinotree> youpi: sure, but that in stuff linking to pthreads
<pinotree> if you do a simple application doing eg main() { fopen +
  fwrite + fclose }, you get no locking
<youpi> so?
<youpi> if you don't have threads, you don't need locks :)
<pinotree> ... unless there is some indirect recursion
<youpi> ?
<pinotree> basically, i was debugging why glibc tests with mtrace() and
  ending with muntrace() would die (while tests without muntrace call
  wouldn't)
<youpi> well, I still don't see what a lock will bring
<pinotree> if you look at the muntrace implementation (in
  malloc/mtrace.c), basically fclose can trigger a malloc hook (because
  of the free for the FILE*)
<youpi> either you have threads, and it's need, or you don't, and it's
  a nop
<youpi> yes, and ?
<braunr> does the signal thread count ?
<youpi> again, in linux, when you don't have threads, the lock is a nop
<youpi> does the signal thread use IO ?
<braunr> that's the question :)
<braunr> i hope not
<youpi> IIRC the signal thread just manages signals, and doesn't
  execute the handler itself
<braunr> sure
<braunr> i was more thinking about debug stuff
<youpi> can't hurt to add them anyway, but let me still doubt that it'd
  fix muntrace, I don't see why it would, unless you have threads
<pinotree> that's what i'm going next
<pinotree> pardon, it seems i got confused a bit
<pinotree> it'd look like a genuine muntrace bug (muntrace → fclose →
  free hook → lock lock → fprint (since the FILE is still set) → malloc
  → malloc hook → lock lock → spin)
<pinotree> at least i got some light over the flockfile stuff, thanks
  ;)
<pinotree> youpi: otoh, __libc_lock_lock (etc) are noop in the base
  implementation, while doing real locks on hurd in any case, and on
  linux only if nptl is loaded, it seems
<pinotree> that would explain why on linux you get no deadlock
<youpi> unless using nptl, that is?
<pinotree> hm no, even with pthread it works
<pinotree> but hey, at least the affected glibc test now passes
<pinotree> will maybe try to do investigation on why it works on linux
  tomorrow

    id:"201211172058.21035.toscano.pino@tiscali.it".

    In context of libpthread.

    IRC, freenode, #hurd, 2013-01-21

    <braunr> ah, found something interesting
<braunr> tschwinge: there seems to be a race on our file descriptors
<braunr> the content written by one thread seems to be retained
  somewhere and another thread writing data to the file descriptor will
  resend what the first already did
<braunr> it could be a FILE race instead of fd one though
<braunr> yes, it's not at the fd level, it's above
<braunr> so good news, seems like the low level message/signalling code
  isn't faulty here
<braunr> all right, simple explanation: our IO_lockfile functions are
  no-ops
<pinotree> braunr: i found that out days ago, and samuel said they were
  okay
<braunr> well, they're not no-ops in libpthreads
<braunr> so i suppose they replace the default libc stubs, yes
<pinotree> so the issue happens in cthreads-using apps?
<braunr> no
<braunr> we don't have cthreads apps any more
<braunr> and aiui, libpthreads provides cthreads compatibility calls to
  libc, so everything is actually using pthreads
<braunr> more buffer management debugging needed :/
<pinotree> hm, so how can it be that there's a multithread app with no
  libpthread-provided file locking?
<braunr> ?
<braunr> file locking looks fine
<braunr> hm, the recursive locking might be wrong though
<braunr> ./sysdeps/mach/hurd/bits/libc-lock.h:#define
  __libc_lock_owner_self() ((void *) __hurd_threadvar_location (0))
<braunr> nop, looks fine too
<braunr> indeed, without stream buffering, the problem seems to go away
<braunr> pinotree: it really looks like the stub IO_flockfile is used
<braunr> i'll try to make sure it's the root of the problem
<pinotree> braunr: you earlier said that there's some race with
  different threads, no?
<braunr> yes
<braunr> either a race or an error in the iostream management code
<braunr> but i highly doubt the latter
<pinotree> if the stub locks are used, then libpthread is not
  loaded... so which different threads are running?
<braunr> that's the thing
<braunr> the libpthread versions should be used
<pinotree> so the application is linked to pthread?
<braunr> yes
<pinotree> i see, that was the detail i was missing earlier
<braunr> the common code looks fine, but i can see wrong values even
  there
<braunr> e.g. when vfprintf calls write, the buffer is already wrong
<braunr> i've made similar tests on linux sid, and it behaves as it
  should
<pinotree> hm
<braunr> i even used load to "slow down" my test program so that
  preemption is much more likely to happen
<pinotree> note we have slightly different behaviour in glibc's libio,
  ie different memory allocation ways (mmap on linux, malloc for us)
<braunr> the problem gets systematic on the hurd while it never occurs
  on linux
<braunr> that shouldn't matter either
<pinotree> ok
<braunr> but i'll make sure it doesn't anyway
<braunr> this mach_print system call is proving very handy :)
<braunr> and also, with load, unbuffered output is always correct too
<pinotree> braunr: you could try the following hack
  http://paste.debian.net/227106/
<braunr> what does it do ?
<pinotree> (yes, ugly as f**k)
<braunr> does it force libio to use mmap ?
<braunr> or rather, enable ?
<pinotree> provides a EXEC_PAGESIZE define in libio, so it makes it use
  mmap (like on linux) instead of malloc

    t/pagesize.

    <braunr> yes, the stub is used instead of the libpthreads code
<braunr> tschwinge: ^
<braunr> i'll override those to check that it fixes the problem
<braunr> hm, not that easy actually
<pinotree> copy their files from libpthreads to sysdeps/mach/hurd
<pinotree> hm right, in libpthread they are not that split as in glibc
<braunr> let's check symbol declaration to understand why the stubs
  aren't overriden by ld
<braunr> _IO_vfprintf correctly calls @plt versions
<braunr> i don't know enough about dynamic linking to see what causes
  the problem :/
<braunr> youpi: it seems our stdio functions use the stub IO_flockfile
  functions
<youpi> really? I thought we were going through cthreads-compat.c
<braunr> yes really
<braunr> i don't know why, but that's the origin of the "duplicated"
  messages issue
<braunr> messages aren't duplicated, there is a race that makes on
  thread reuse the content of the stream buffer
<braunr> one*
<youpi> k, quite bad
<braunr> at least we know where the problem comes from now
<braunr> youpi: what would be the most likely reason why weak symbols
  in libc wouldn't be overriden by global ones from libpthread ?
<youpi> being loaded after libc
<braunr> i tried preloading it
<braunr> i'll compare with what is done on wheezy
<youpi> you have the local-dl-dynamic-weak.diff patch, right?
<braunr> (on squeeze, the _IO_flockfile function in libc seems to do
  real work unlike our noop stub)
<braunr> it's the debian package, i have all patches provided there
<braunr> indeed, on linux, libc provides valid IO_flock functions
<braunr> ./sysdeps/pthread/flockfile.c:strong_alias (__flockfile,
  _IO_flockfile)
<braunr> that's how ntpl exports it
<braunr> nptl*
<pinotree> imho we should restructure libpthread to be more close to
  nptl
<braunr> i wish i knew what it involves
<pinotree> file structing for sources and tests, for example
<braunr> well yes obviously :)
<braunr> i've just found a patch that does exactly that for linuxthreads
<pinotree> that = fix the file locking?
<braunr> in addition to linuxthreads/lockfile.c (which we also
  equivalently provide), there is
  linuxthreads/sysdeps/pthread/flockfile.c
<braunr> no, restructiring
<braunr> restructuring*
<braunr> i still have only a very limited idea of how the glibc sources
  are organized
<pinotree> the latter is used as source file when compiling flockfile.c
  in stdio-common
<braunr> shouldn't we provide one too ?
<pinotree> that would mean it would be compiled as part of libc proper,
  not libpthread
<braunr> yes
<braunr> that's what both linuxthreads and nptl seem to do
<braunr> and the code is strictly the same, i.e. a call to the internal
  _IO_lock_xxx functions
<youpi> I guess that's for the hot-dlopen case
<youpi> you need to have locks properly taken at dlopen time
<braunr> youpi: do you mean adding an flockfile.c file to our sysdeps
  will only solve the problem by side effect ?
<braunr> and that the real problem is that the libpthread versions
  aren't used ?
<youpi>  yes
<braunr> ok
<braunr> youpi: could it simply be a versioning issue ?
<youpi> could be
<braunr> it seems so
<braunr> i've rebuilt with the flockfile functions versioned to 2.2.6
  (same as in libc) and the cthreads_compat functions are now used
<braunr> and the problem doesn't occur any more with my test code
<braunr> :)
<youpi> could you post a patch?
<braunr> i need a few info before
<youpi> it'd be good to check which such functions are hooked
<braunr> i suppose the version for functions declared in libpthreads
  shouldn't change, right ?
<youpi> yes
<braunr> ok
<youpi> they didn't have a vresion before
<braunr> shall i commit directly ?
<youpi> so it should be fine
<braunr> well, they did
<braunr> 2.12
<youpi> yes, but please tell me when it's done
<braunr> sure
<youpi> so I can commit that to debian's eglibc
<youpi> I mean, before we integrated libpthread build into glibc
<youpi> so they never had any version before 2.12
<braunr> ok
<youpi> basically we need to check the symbols which are both in
  libpthread and referenced in libc
<youpi> to make sure they have the same version in the reference
<braunr> ok
<youpi> only weak references need to be checked, others would have
  produced a runtime error
<braunr> youpi: done
<braunr> arg, the version i mention in the comment is wrong
<braunr> i suppose people understand nonetheless
<youpi> probably, yes
<braunr> ah, i can now appreciate the headache this bug hunting gave me
  these last days :)

    IRC, freenode, #hurd, 2013-01-22

    <youpi> braunr: commited to debian glibc
<youpi> btw, it's normal that the program doesn't terminate, right?
<youpi> (i.e. it's the original bug you were chasing)
<braunr> youpi: about your earlier question (yesterday) about my test
  code, it's expected to block, which is the problem i was initially
  working on
<youpi> ok, so all god
<youpi> +o

  • t/pagesize

    IRC, freenode, #hurd, 2012-11-16

    <pinotree> tschwinge: somehow related to your t/pagesize branch: due to
  the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h
  switches the allocation modes from mmap to malloc

    id:"87mxd9hl2n.fsf@kepler.schwinge.homeip.net".

    IRC, freenode, #hurd, 2013-01-21

    <braunr> why is it a hack ?
<pinotree> because most probably glibc shouldn't rely on EXEC_PAGESIZE
  like that
<braunr> ah
<pinotree> there's a mail from roland, replying to thomas about this
  issue, that this use of EXEC_PAGESIZE to enable mmap or not is just
  wrong
<braunr> ok
<pinotree> (the above is
  http://thread.gmane.org/87mxd9hl2n.fsf@kepler.schwinge.homeip.net )
<braunr> thanks
<pinotree> (just added the reference to that in the wiki)
<braunr> pinotree: btw, what's wrong with using malloc instead of mmap
  in libio ?
<pinotree> braunr: i'm still not totally sure, most probably it should
  be slightly slower currently
<braunr> locking contention ?
<braunr> pinotree:
  http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html
<braunr> pinotree: it looks to me there is now no valid reason not to
  use malloc
<braunr> the best argument for mmap is that libio requires zeroed
  memory, but as the OP says, zeroing a page is usually more expensive
  than a small calloc (even on kernel that keep a list of zeroed pages
  for quick allocations, frequent mmaps() often make this list empty)
<pinotree> braunr: mmap allocations in libio are rounded to the page
  size
<braunr> well they have to

  • LD_DEBUG

    IRC, freenode, #hurd, 2012-11-22

    <pinotree> woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and
  then sigsegv
<tschwinge> Yeah, that's known for years...  :-D
<tschwinge> Probably not too difficult to resolve, though.

  • Verify baseline changes, if we need any follow-up changes:

    • a11ec63713ea3903c482dc907a108be404191a02
    • 7e2b0c8562b35155820f87b5ff02a8b6850344cc
    • 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9
    • 5a2a1d75043138e696222ced4560de2fb90b8024
    • 5ae958d74180e2572d198bd7872c86f391de6da7
    • 5b08ac571ff8e94fe96511a532f0d20997de5f52
    • 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26
    • b2ef2c014b9c66995a3eb4f310ae7c5c510279bf
    • 63c4ed22b5048c8701d8806026c23cc95f0df756
    • ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c
    • e35fcef8b739ed24e083ff8a3078ac14e101cf67
    • 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba
    • 8a492a675e566dc1e666df0a86cbf541442cb179
    • 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef
    • c86434ccb576a3ce35b5a74f72b9f03bd45b522a
    • d22e4cc9397ed41534c9422d0b0ffef8c77bfa53
    • 15bac72bac03faeb3b725b1d208c62160f0c3ad7
    • c08fb0d7bba4015078406b28d3906ccc5fda9d5a
    • 10b3bedcb03386cc280113f552479793e4bac35f
    • 754f7da38b0904b4b989d3500cc8dd5be625cf6a
    • 3cdaa6adb113a088fdfb87aa6d7747557eccc58d
    • 962dba7828cf251a9025ccb43bc6effa30379b72
    • 3162f12e58c3a848db883916843b332b9f8c9d39
    • 1c06ba3100847da6bd1f2e011dc24fa8debd9615
    • 84b9230c404aed4fd3a7bb3d045ca367043dde8c
    • 090555538d4347a52807ba9f08cf20ed13206afe
    • 817328eea788c746131cf151b64fd250200da333
    • c3758feebf7c8786231465da664743c6f0ec79cc
    • 1ac7a2c7b448c851eb8976fcc290a906a4075203
    • c21cc9bcb38a87ff638d1099ca871d94a2192b31
    • 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde
    • b8b4863d78bf26b39918fc753b03ed98ef262903
    • b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1
    • 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- _dl_map_object in sysdeps/mach/hurd/dl-sysdep.c
    • 0e516e0e14f2f9783a21cd1727bc53776341f857
    • a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc
    • cf7c9078a5acdbb435498ace92cd81009637a971
    • db753e2cfb2051ebf20dc089f87c5b1297cc2cff
    • 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good.
    • 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b
    • 451f001b50870604e1f2daef12f04f9f460d3997 + a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484. nptl/Versions [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff. We don't even define it yet. Also see glibc libc alloca cutoff should be lowered.
    • 1086d70d916fd0eb969b3d89ff88abd35f6a5c34
    • cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca
    • 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f
    • 68dc949774cb651d53541df4abdc60327f7e096b
    • 70181fddf1467996bea393d13294ffe76b8a0853
    • a77e8cbc394ab098aa1fc3f0a6645a38348d21ca
    • 32465c3ea007065acd8ca8199f130cdf4068130d
    • 18ba70a559c52719fd94a713cc380514d9d19125
    • 620a05296fe3380b7441ba7720e8b25c48a8c28c
    • [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- Fix memory leak in TLS of loaded objects. Do we need to replicate nptl/allocatestack.c hunk?
    • 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 + 1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- Fix pathconf(_PC_BUF_SIZE).
    • 28377d1bf58625172a1734b92e835591d4d23a18 -- Optimize fdopendir a bit.
    • 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 + 6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- Fix Linux getcwd for long paths
    • f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- Fix sched_setscheduler call in spawn implementation
    • 3b85df27870a47ed1db84e948e37a5a50a178a92 + f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf
    • 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- Fix reporting of invalid timeouts in emulated pselect
    • ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- strndup -> __strndup; strndupa?
    • 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- Nicer output for negative error numbers in strerror_r. Change needed for sysdeps/mach/_strerror.c?
    • 7ea72f99966a65a56aedba817ee2413ff9b1f23c + adcd5c15d2a37794d021104160b425ff61f88219 -- Always fill output buffer in XPG strerror function. Change needed for sysdeps/mach/xpg-strerror.c?
    • a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss (debugging, profiling). Does it work?
    • b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 + 80e2212d8e59933a1641f029ebd360526ff0e074 + 4997db742946d08be4378cf91221f558f928bc73 -- Don't document si_code used for raise(). Also for bits/siginfo.h?
    • 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work? Probably not: needs /proc/[PID]/auxv, /proc/[PID]/exe, /proc/[PID]/mem (, procfs).
    • 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- --experimental-malloc. Watch what happens.
    • 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- -defsym=_begin=0. Watch what happens. Native build: apparently OK.
    • f781ef4015504e8a1da649c266584976238aa079 (--with-default-link) + 1b74661a6b93a892ecb1c717dedeedba5c2a976c + fd5e21c75d8e9221d766f4bc922a237265514ec2. Watch what happens. Native build: use-default-link = no.
    • de283087c74f720cf8a7171972e72b5fa2b45e79 (Handle Lustre filesystem), 4e5f31c847982997c856f03bbc35134e9fd0f61f (Handle ext4 in {,f}pathconf). What about stuff like that for us?
    • d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (Find readelf with AC_CHECK_TOOL). Aren't there more in other configure.in and Makefile files?
    • 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (Add read barriers in cancellation initialization). Is this needed in other places, too?
    • [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (Align x86 TCB to 64 bytes). Probably we have hidden somewhere such a constant, too (in libpthread).
    • d96de9634a334af16c0ac711074c15ac1762b23c + ecb1482ffd85fd3279642b1dc045aa867ad4d415 (Try shell in posix_spawn* only in compat mode). Change looks good, but what about SPAWN_XFLAGS_TRY_SHELL for us?
    • 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (Make several tool features mandatory and simplify the code.). Generally looks good.
      • locale/global-locale.c: Apparently, no one is using _HURD_THREADVAR_LOCALE. But it is exported via hurd/threadvar.h.
      • mach/devstream.c: reversed. Fixed in t/repair-mach_devstream.c.
      • malloc/arena.c: should be OK.
    • Remove support for !USE___THREAD. d063d164335938d557460bebaa7cfe388157b627 (generally looks good; csu/errno-loc.c (should be OK); include/errno.h (fixed)) + (de82006d43e198fd162807c9adc720c7ebd728a3 + 037e9fe21c92216ef7032ea2796781ec27ca182a) + 995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) + bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok).
    • [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (malloc: Remove all kinds of unused configuration options and dead code.). NO_STARTER changes (should be OK).
    • [high] pagesize, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (Simplify malloc initialization); aebae0537dcb408100b88c6b7647a7e858c43237, sourceware [BZ #11929]. Is this all kosher for us? See id:"87mxd9hl2n.fsf@kepler.schwinge.homeip.net".
    • [OK] 83cd14204559abbb52635006832eaf4d2f42514a (Remove --wth-tls option, TLS support is required).
    • a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (Fix invalid conversion in __cmsg_nxthdr). Probably just a C++ thing and not relevant for us; see id:"87r52nk1kx.fsf@kepler.schwinge.homeip.net".
    • [low] mmap, 110946e473b38fc3896212e416d9d7064fecd5b7. Kosher with respect to our mmap peculiarities?
    • [OK] __attribute__ ((__leaf__)), BZ #13344, aa78043a4aafe5db1a1a76d544a833b63b4c5f5c + 49a43d80ec5c97cf6136b1ee2687414773b2d5aa + 3871f58f065dac3917eb18220a479e9591769c8c + 9beb2334930db81ceada5aa6051fe5ac0554db32 + 0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 + edc5984d4d18296d7aa3d8f4ed8f7336a743170e + 57769839788e2c62b68d9dfbf4b35052321278ba. http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html.
    • [low] conformtest, 3134156779108fe8b46e0f4cd60d837572faaa93 + 4efeffc1d583597e4f52985b9747269e47b754e2 + d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror bits/siginfo.h changes.
    • [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe, id:"4F3BE241.9090409@mentor.com" -- anything needed for us?
    • [low] libc-lockP.h 9463518d0d314d7bd0160315e0ef30e15be08985 -- probably should do similar changes, also to the generic file.
    • [low] bits/socket.h/bits/socket_type.h id:"Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk" 02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same for the generic version as used by GNU Hurd.
    • [low] CFI for _start, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4, id:"20120316180551.GA6291@host2.jankratochvil.net" -- what about other architectures?
    • linkobj/libc.so, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to adapt for (conditional?) Sun RPC reversion (if that was the original cause for the patch)?
    • [low] Add __fsword_t and use it in bits/statfs.h, 3e5aef87d76cfa7354f2b0d82b96e59280720796, id:"20120517134700.GA19046@intel.com" -- only updates one copy of bits/statfs.h; update the others, too, for consistency.
    • [low] 789bd351b45f024b7f51e4886bf46b8e887ab6da: remove libc_hidden_def in sysdeps/mach/hurd/accept4.c?
    • 0948c3af9dfb3bc1312d6bed2f3a6bfd4e96eef4, b80af2f40631871cf53a5e39d08d5d5516473b96, 04570aaa8ad88caad303f8afe469beb4cf851e17 _dl_initial_dtv: OK?
    • [very low] ea4d37b3169908615b7c17c9c506c6a6c16b3a26 Implement POSIX-generic sleep via nanosleep rather than SIGARLM.: any benefit using that one (with sysdeps/mach/nanosleep.c) instead of sysdeps/mach/sleep.c?
    • baseline
    • ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd, 2012-11-20, pinotree: »tschwinge: i agree on your comments on ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's sleep.c is buggy (not considers interruption, extra time() (= RPC) call)«.

Update

baseline, t/regenerate_configure (could now be removed), t/master_backports, t/eglibc_backports, t/host-independency, tschwinge/Roger_Whittaker

Build

Here's a log of a glibc build run; this is from our Git repository's 60f4d2f33666d77ac018cb9956675dcad04bb996 (2013-02-12; fbeafedeea37e0af1984a6511018d159f5ceed6a (2012-11-03)) sources, run on coulomb.SCHWINGE.

$ export LC_ALL=C
$ ../Roger_Whittaker/configure AUTOCONF=: --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build
[...]
$ make install_root=/INVALID 2>&1 | tee log_build_
[...]

This takes up around 550 MiB, and needs roughly X min on kepler.SCHWINGE and 100 min on coulomb.SCHWINGE.

Analysis

$ toolchain/logs/process glibc build fetch coulomb.SCHWINGE

TODO.

  • With GCC >= 4.5, there's a ton of these warnings:

    hurd/hurd.h: In function '__hurd_fail':
hurd/hurd.h:73: warning: case value '0' not in enumerated type 'error_t'

    ... as well as a few individual instances:

    hurdselect.c: In function '_hurd_select':
hurdselect.c:265: warning: case value '0' not in enumerated type 'error_t'
get-host.c: In function '_hurd_get_host_config':
get-host.c:38: warning: case value '0' not in enumerated type 'error_t'
hurdmsg.c: In function '_S_msg_get_init_ints':
hurdmsg.c:186: warning: case value '0' not in enumerated type 'error_t'
hurdmsg.c: In function '_S_msg_set_init_ints':
hurdmsg.c:273: warning: case value '0' not in enumerated type 'error_t'
intr-msg.c: In function '_hurd_intr_rpc_mach_msg':
intr-msg.c:363: warning: case value '0' not in enumerated type 'error_t'
sysdeps/mach/hurd/setitimer.c: In function 'timer_thread':
sysdeps/mach/hurd/setitimer.c:117: warning: case value '0' not in enumerated type 'error_t'
sysdeps/mach/hurd/wait4.c: In function '__wait4':
sysdeps/mach/hurd/wait4.c:40: warning: case value '0' not in enumerated type 'error_t'
sysdeps/mach/hurd/fork.c: In function '__fork':
sysdeps/mach/hurd/fork.c:423: warning: case value '0' not in enumerated type 'error_t'
sysdeps/mach/hurd/spawni.c: In function '__spawni':
sysdeps/mach/hurd/spawni.c:600: warning: case value '0' not in enumerated type 'error_t'
sysdeps/mach/hurd/setpriority.c: In function 'setonepriority':
sysdeps/mach/hurd/setpriority.c:66: warning: case value '0' not in enumerated type 'error_t'
sysdeps/mach/hurd/ioctl.c: In function 'send_rpc':
sysdeps/mach/hurd/ioctl.c:177: warning: case value '0' not in enumerated type 'error_t'
sysdeps/mach/hurd/ioctl.c: In function '__ioctl':
sysdeps/mach/hurd/ioctl.c:306: warning: case value '0' not in enumerated type 'error_t'

    id:"20120723195143.7F8142C0B9@topped-with-meat.com".

  • baseline fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b (or probably Samuel's mmap backport) introduces:

    ../sysdeps/mach/hurd/mmap.c: In function '__mmap':
../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default]
../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default]
../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default]
../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default]

  • baseline fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b introduces:

    nscd_gethst_r.c: In function '__nscd_get_nl_timestamp':
nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration]

    This was already present before:

    nscd_gethst_r.c: In function 'nscd_gethst_r':
nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]

  • baseline 2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032 introduces:

    tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]

  • baseline fc56c5bbc1a0d56b9b49171dd377c73c268ebcfd..cbc818d0ee66065f3942beffdca82986615aa19a introduces

    +gcc-4.6 tst-printf-round.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.
+tst-printf-round.c: In function 'do_test':
+tst-printf-round.c:203:11: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
+tst-printf-round.c:208:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
+tst-printf-round.c:216:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
+tst-printf-round.c:224:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
+tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'


 gcc-4.6 test-wcschr.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
+In file included from test-wcschr.c:2:0:
+../string/test-strchr.c: In function 'check1':
+../string/test-strchr.c:249:3: warning: passing argument 1 of 'stupid_STRCHR' from incompatible pointer type [enabled by default]
+../string/test-strchr.c:77:1: note: expected 'const wchar_t *' but argument is of type 'char *'
+../string/test-strchr.c:249:22: warning: initialization from incompatible pointer type [enabled by default]
+../string/test-strchr.c:252:5: warning: passing argument 2 of 'check_result' from incompatible pointer type [enabled by default]
+../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'
+../string/test-strchr.c:252:5: warning: passing argument 4 of 'check_result' from incompatible pointer type [enabled by default]
+../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'

Install

TODO.

$ make install_root="$PWD".install install 2>&1 | tee log_install
[...]

This takes up around 100 MiB, and needs roughly X min on kepler.SCHWINGE and 16 min on coulomb.SCHWINGE.

Analysis

$ toolchain/logs/process glibc install fetch coulomb.SCHWINGE

TODO.

Testsuite

$ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test
[...]

This needs roughly X min on kepler.SCHWINGE and 60 min on coulomb.SCHWINGE.

Specifying fast-check=yes disables the conformtest which takes 1.75 h (out of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't our most critical issue to solve.

Analysis

$ toolchain/logs/process glibc test fetch coulomb.SCHWINGE

Failures, mostly in order of appearance:

  • check-abi, check-abi-libmachuser, check-abi-libhurduser, check-abi-libBrokenLocale, check-abi-libm, check-abi-libdl, check-abi-libcrypt, check-abi-libresolv, check-abi-librt, check-abi-libnsl, check-abi-libutil, check-abi-libc, check-abi-ld, c++-types.data

    Reference files are missing.

  • math/test-float.out, math/test-double.out

    A handful of ULP failures.

  • math/test-ldouble, math/test-ildoubl, math/test-ifloat, math/test-idouble

    SIGSEGV. Or SIGILL.

  • stdlib/bug-getcontext.out

    getcontext failed, errno: 1073741902.

    Not implemented. In 8958805c11c741d9211e20612c86271d906c9a0b testing, stdlib/bug-getcontext.out now says: Skipping test; no support for FP exceptions., in cba1c83ad62a11347684a9daf349e659237a1741 testing, it's back to the previous failure.

  • stdlib/tst-secure-getenv.out

    open (/proc/self/exe): No such file or directory

    Needs /proc/self/exe.

  • stdlib/tst-strtod-round.out

    strtold (-0x0.7p-16445) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)
strtold (-0x0.7p-16494) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)

  • stdio-common/bug22.out

    Timed out: killed the child process

    Known problem.

  • libio/tst-atime.out, dirent/tst-fdopendir.out

    libio/tst-atime.out:

    atime has not changed

    Due to ext2fs --no-atime.

    dirent/tst-fdopendir.out:

    directory atime changed

    Due to ext2fs --atime (default).

  • libio/tst-fopenloc.check, posix/bug-regex31-mem, posix/tst-fnmatch-mem, misc/tst-error1-mem

    Memory not freed:
-----------------
   Address     Size     Caller
0x0807e268   0x8000  at 0x10c71c4

    Caused by different memory allocation way in libio, see id:"87mxd9hl2n.fsf@kepler.schwinge.homeip.net"

  • dlfcn/bug-atexit3.out

    Originally:

    dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory

    See id:"20090420002344.11798.qmail@s461.sureserver.com". Hacked around with ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./. This is a bug in the glibc test harness. Should probably use some configure magic akin to the fixincludes stuff (gcc-4.4 -print-file-name=libstdc++.so.6, etc.).

    Even if that that is being worked around, the tests nowadays (packaging libpthread) fail with:

    dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)

  • dlfcn/tststatic.out, dlfcn/tststatic2.out

    SIGSEGV.

    LD_LIBRARY_PATH doesn't contain the mach and hurd directories; yet the test shouldn't just SIGSEGV.

  • dirent/opendir-tst1.out, dirent/tst-fdopendir2.out

    dirent/opendir-tst1.out:

    `opendir' succeeded on a FIFO???

    dirent/tst-fdopendir2.out:

    fdopendir with normal file descriptor did not fail

    opendir and fdopendir do not return ENOTDIR if fd is not a directory.

  • posix/tst-waitid.out

    Intermittent.

    SIGCHLD for stopped status 0
SIGCHLD for stopped pid -1
SIGCHLD for killed code 1
SIGCHLD for killed status 0
SIGCHLD for killed pid -1

  • posix/bug-glob2.out

    Timed out: killed the child process

  • posix/annexc.out

    Failure ignored by the glibc testsuite.

  • posix/tst-getconf.out

    Ends with:

    getconf POSIX_ALLOC_SIZE_MIN /: [...]/posix/getconf: pathconf: /: Invalid argument

    It fails because of unimplemented pathconf cases: _PC_ALLOC_SIZE_MIN, _PC_REC_INCR_XFER_SIZE, _PC_REC_MAX_XFER_SIZE, _PC_REC_MIN_XFER_SIZE, _PC_REC_XFER_ALIGN, _PC_SYMLINK_MAX, _PC_2_SYMLINKS.

    _CS_GNU_LIBPTHREAD_VERSION is provided by libpthread when compiled as add-on.

  • posix/tst-vfork3-mem

    + 0x0804cee0 Alloc 10 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 11 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 12 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 17 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 18 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 19 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 20 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 25 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 26 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 27 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 28 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 33 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 34 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 35 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 36 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 41 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 42 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 43 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 44 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 49 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 50 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 51 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 52 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 57 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 58 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 59 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 60 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 65 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 66 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 67 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 68 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 73 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 74 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 75 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
+ 0x0804cfa8 Alloc 76 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x00000008 Alloc 81 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
+ 0x0804cee0 Alloc 82 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
+ 0x0804cf90 Alloc 83 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
- 0x0804c8d8 Free 84 was never alloc'd 0x10955fc
- 0x0804c960 Free 87 was never alloc'd 0x115672f
- 0x0804c9b8 Free 88 was never alloc'd 0x1156737


Memory not freed:
-----------------
   Address     Size     Caller
0x0804cfa8     0x73  at 0x10df0c8
0x00000008        0  at 0x10df0c8

    Perhps because we implement vfork in terms of fork (posix/vfork.c)?

  • io/test-lfs.out

    /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build/io/test-lfs: cannot write test string to large file: Invalid argument

  • io/tst-futimesat.out

    file created
futimesat failed

    futimesat is a stub.

  • resource/bug-ulimit1.out

    Result of ulimit (UL_SETFSIZE, 10000): 0
Result of ulimit(UL_GETFSIZE): 10000

    Buggy sysdeps/unix/bsd/ulimit.c return values.

    id:"201211182342.51619.toscano.pino@tiscali.it"

    Fixed in glibc >= 2.18.

  • misc/tst-pselect.o

    tst-pselect.c: In function 'do_test':
tst-pselect.c:33:17: error: 'SA_NOCLDWAIT' undeclared (first use in this function)

  • gmon/tst-sprofil.out

    Floating point exception

  • nss//libnss_test1.so

    [...]/nss/nss_test1.os: In function `_nss_test1_getpwent_r':
[...]/nss/nss_test1.c:60: undefined reference to `pthread_mutex_lock'
[...]/nss/nss_test1.c:85: undefined reference to `pthread_mutex_unlock'

  • rt/tst-timer.out

    No message.

  • rt/tst-timer2.o

    tst-timer2.c: In function 'do_test':
tst-timer2.c:33:23: error: 'SIGRTMIN' undeclared (first use in this function)

  • rt/tst-aio2, rt/tst-aio3, rt/tst-aio9, rt/tst-aio10, rt/tst-mqueue3, rt/tst-mqueue5.o, rt/tst-mqueue6, rt/tst-mqueue8, rt/tst-timer3, rt/tst-timer4.o, rt/tst-timer5.o, rt/tst-cputimer1.o, rt/tst-cputimer2.o, rt/tst-cputimer3.o, elf/tst-thrlock

    [...]/rt/tst-aio2.o: In function `do_test':
[...]/rt/tst-aio2.c:62: undefined reference to `pthread_barrier_init'
[...]/rt/tst-aio2.c:94: undefined reference to `pthread_barrier_wait'
[...]/rt/tst-aio2.o: In function `thrfct':
[...]/rt/tst-aio2.c:35: undefined reference to `pthread_barrier_wait'


tst-mqueue5.c: In function 'rtmin_handler':
tst-mqueue5.c:50:14: error: 'SIGRTMIN' undeclared (first use in this function)


[...]/rt/tst-mqueue6.o: In function `do_test':
[...]/rt/tst-mqueue6.c:127: undefined reference to `pthread_attr_init'
[...]/rt/tst-mqueue6.c:149: undefined reference to `pthread_attr_setguardsize'
[...]/rt/tst-mqueue6.c:211: undefined reference to `pthread_attr_setguardsize'
[...]/rt/tst-mqueue6.c:262: undefined reference to `pthread_attr_destroy'
[...]/rt/tst-mqueue6.c:128: undefined reference to `pthread_attr_setguardsize'
[...]/rt/tst-mqueue6.o: In function `fct':
[...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_self'
[...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_getattr_np'
[...]/rt/tst-mqueue6.c:88: undefined reference to `pthread_attr_getguardsize'
[...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'
[...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'


[...]/elf/tst-thrlock.o: In function `do_test':
[...]/elf/tst-thrlock.c:38: undefined reference to `pthread_create'
[...]/elf/tst-thrlock.c:48: undefined reference to `pthread_join'

  • rt/tst-aio8.out

    r = -1, e = 1073741902 (Function not implemented)

    Should work with id:"201209302353.51055.toscano.pino@tiscali.it" in libpthread.

  • debug/tst-chk1.out

    Intermittent. Timeout. Unknown.

  • debug/tst-chk2.out, debug/tst-chk3.out, debug/tst-lfschk2.out, debug/tst-lfschk3.out

    Unknown.

  • debug/tst-chk4.out, debug/tst-chk5.out, debug/tst-chk6.out, debug/tst-lfschk4.out, debug/tst-lfschk5.out, debug/tst-lfschk6.out

    [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)
[...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libgcc_s.so.1)

  • debug/tst-longjmp_chk2.out

    SIGSEGV.

    not on alternate stack
 in signal handler
 on alternate stack
 out of signal handler
 on alternate stack

    It says alternate stack.

  • inet/tst-ether_line.o

    tst-ether_line.c: In function 'do_test':
tst-ether_line.c:19:19: error: 'ETH_ALEN' undeclared (first use in this function)

    Will either need a hurd/netinet/if_ether.h that includes <net/if_ether.h>, or can do that in the generic netinet/if_ether.h? See also sourceware [BZ #11142].

  • login/tst-grantpt.out

    posix_openpt(O_RDWR) failed
errno 1073741902 (Function not implemented)

    posix_openpt is a stub.

    grantpt(): expected: return = -1, errno = 1073741846
           got: return = -1, errno = -303

    grantpt (actually ptsname_r), does not fail with ENOTTY when the fd does not refer to a PTY master.

  • elf/tst-stackguard1-static.out, elf/tst-stackguard1.out

    differences 0 defaults 0
stack guard canaries are not randomized enough
nor equal to the default canary value

    Sometimes times out.

  • elf/tst-tls9-static.out

    SIGSEGV.

  • elf/tst-dlmopen1.out

    SIGSEGV.

  • elf/tst-audit1.out, elf/tst-audit2.out

    SIGKILL.

  • elf/check-textrel.out

    $BUILDDIR/libc.so.dyn: *** text relocations used

  • elf/check-execstack.out

    $BUILDDIR/libc.so.phdr: *** executable stack signaled

  • elf/check-localplt.out

    Around 500 or so Extra PLT reference.

  • check-local-headers.out

    A lot. Including /usr/include/device/*.h, /usr/include/mach/*.h, /usr/include/hurd/*.h.

Earlier failures; no longer seen:

  • test-assert-perr.out

    Fails intermittently. Unknown.

  • test-multiarch.out

    Needs /proc/cpuinfo providing the flags line.

  • elf/tst-array*

    No longer fail with GCC 4.7. id:"50950082.1070906@df1tl.local.here".

  • io/ftwtest, posix/globtest, iconvdata/iconv-test, intl/tst-gettext, malloc/tst-mtrace, elf/tst-pathopt, iconvdata/tst-tables, grp/tst_fgetgrent, posix/wordexp-tst, localedata/bug-setlocale1.out, posix/tst-getconf

    /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory

    Looking into localedata/bug-setlocale1.c, it is clear what it going on: only the root of the build directory is added for --library-path, but none of the other directories that are additionally used. This is a bug in the glibc test harness. Hacked around by ln -s mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./. Hopefully the other instances are similar.

  • assert/test-assert.out

    Fails sometimes...

  • math/test-fenv.out

    Used to fail (is listed in Debian eglibc-2.13-21's expected-results-i486-gnu-libc), but something between 22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and 005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely Jérémie's signaling work.

  • elf/tst-unused-dep.out (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d, sourceware [BZ #13706], id:"4F4210C1.1090704@redhat.com")

    Unused direct dependencies:
        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2

    As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes -- correct?

Compared to Debian:

$ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test  > log_test.filtered
$ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered