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

General information

• Versioning

Sources

Debian Cheat Sheet

Configuration

Last reviewed up to the Git mirror's 9a869d822025be8e43b78234997b10bf0cf9d859 (2014-02-07) 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 [BZ #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

  We have posted a Google Summer of Code project proposal:

  Fix Compatibility Problems Exposed by Testsuites, Implement Missing Interfaces in glibc for GNU Hurd

  Fix Compatibility Problems Exposed by Testsuites

  A number of software packages come with extensive testsuites. Some notable ones are glibc, gnulib, Perl, Python, GNU Coreutils, and glib. While these testsuites were written mostly to track regressions in the respective packages, some of the tests fail on the Hurd in general.

  There is also the Open POSIX Testsuite which is more of a whole system interface testing suite.

  Then, there is the File System Exerciser which we can use to test our file system servers for conformity.

  While in some cases these might point to wrong usage of system interfaces, most of the time such failures are actually caused by shortcomings in Hurd's implementation of these interfaces. These shortcomings are often not obvious in normal use, but can be directly or indirectly responsible for all kinds of failures. The testsuites help in isolating such problems, so they can be tracked down and fixed.

  This task thus consists in running some of the mentioned testsuites (and/or any other ones that come to mind), and looking into the causes of failures. The goal is to analyze all failures in one or more of the listed testsuites, to find out what shortcomings in the Hurd implementation cause them (if any), and to fix at least some of these shortcomings.

  Note that this task somewhat overlaps with the Perl/Python task. Here the focus however is not on improving the support for any particular program, but on fixing general problems in the Hurd.

  A complementary task is adding a proper unit testing framework to the GNU Hurd's code base, and related packages.

  Implement Missing Interfaces in glibc for GNU Hurd

  A related project is to implement missing interfaces for GNU Hurd (glibc wiki), primatily in glibc.

  In glibc's Linux kernel port, most simple POSIX interfaces are in fact just forwarded to (implemented by) Linux kernel system calls. In contrast, in the GNU Hurd port, the POSIX (and other) interfaces are actually implemented in glibc on top of the Hurd RPC protocols. A few examples: getuid, open, rmdir, setresuid, socketpair.

  When new interfaces are added to glibc (new editions of POSIX and similar standards, support for new editions of C/C++ standards, new GNU-specific extensions), generally ENOSYS stubs are added, which are then used as long as there is no real implementation, and often these real implementations are only done for the Linux kernel port, but not GNU Hurd. (This is because most of the contributors are primarily interested in using glibc on Linux-based systems.) Also, there is quite a backlog of missing implementations for GNU Hurd.

  In coordination with the GNU Hurd developers, you'd work on implementing such missing interfaces.

  ---

  These are very flexible tasks: while less experienced students should be able to tackle at least a few of the easier problems, other issues will be challenging even for experienced hackers. No specific previous knowledge is required; only fairly decent C programming skills. While tracking down the various issues, the student will be digging into the inner workings of the Hurd, and thus gradually gaining the knowledge required for Hurd development in general.

  Possible mentors: Samuel Thibault (youpi)

  Exercise: Take a stab at one of the testsuite failures, or missing implementation, and write a minimal testcase exposing the underlying problem. Actually fixing it would be a bonus of course -- but as it's hard to predict which issues will be easy and which will be tricky, we will already be satisfied if the student makes a good effort. (We hope to see some discussion of the problems in this case though )

  Posted 2010-03-27 16:31:56 UTC

  Copyright © 2010, 2011, 2014 Free Software Foundation, Inc.

  • Edit
  • ?Discussion

  Many are missing for GNU Hurd, 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 bit of a commented list, otherwise go looking in /usr/include/i386-gnu/gnu/stubs.h on a Debian GNU/Hurd system, or the respective file from a fresh glibc build.

  AT_EMPTY_PATH, CLOCK_BOOTTIME, CLOCK_BOOTTIME_ALARM, CLOCK_REALTIME_ALARM, O_PATH, O_TMPFILE (ffdd31816a67f48697ea4d6b852e58d2886d42ca), PTRACE_* (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27, b1b2aaf8eb9eed301ea8f65b96844568ca017f8b, 521c6785e1fc94d1f501743e9a40af9e02797df3), RLIMIT_RTTIME, SEEK_DATA (unistd.h), SEEK_HOLE (unistd.h) clock_adjtime, fallocate, fallocate64, name_to_handle_at, open_by_handle_at, posix_openpt, process_vm_readv, process_vm_writev, 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
    

  • tls-threadvar

  • futimesat

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

  • futimens

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

    <youpi> it seems apt 0.9.15.1 has troubles downloading packages
      etc., as opposed to apt 0.9.15
    <youpi> ah, that version uses futimens unconditionally
    <youpi> and we haven't implemented that yet
    <azeem> did somebody file a bug for that apt-get issue?
    <youpi> I haven't
    <youpi> I'll commit the fix in eglibc
    <youpi> but perhaps a bug report would be good for the kfreebsd
      case
    

  • 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.

    IRC, OFTC, #debian-hurd, 2013-09-09:

    <gg0> does hurd MADV_DONTNEED or MADV_FREE or none?
      http://sources.debian.net/src/jemalloc/3.4.0-1/include/jemalloc/jemalloc_defs.h.in#L239
    <gg0> seems it builds by defining JEMALLOC_PURGE_MADVISE_DONTNEED
      but i don't know what i'm talking about, so it could build with
      JEMALLOC_PURGE_MADVISE_FREE as well
    

    IRC, OFTC, #debian-hurd, 2013-09-10:

    <youpi> gg0: it implements none, even if it defines DONTNEED (but
      not FREE)
    

    See also:

    gnash (0.8.11~git20130903-1) unstable; urgency=low
    
    
      * Git snapshot.
        + Embedded jemalloc copy has been replaced by system one.
          [...]
          - Disable jemalloc on hurd and kfreebsd-*. No longer disabled upstream.
    

  • msync

    Then define _POSIX_MAPPED_FILES, _POSIX_SYNCHRONIZED_IO.

  • epoll, sys/epoll.h

    Used by wayland, for example.

    IRC, freenode, #hurd, 2013-08-08:

    <nalaginrut> is there any possible to have kquque/epoll alike
      things in hurd? or there is one?
    <braunr> nalaginrut: use select/poll
    <nalaginrut> is it possible to implement epoll?
    <braunr> it is
    <braunr> we don't care enough about it to do it
    <braunr> (for now)
    <nalaginrut> well, since I wrote a server with Guile, and it could
      take advantage of epoll, never mind, if there's no, it'll use
      select automatically
    <nalaginrut> but if someday someone care about it, I'll be
      interested on it
    <braunr> epoll is a scalability improvement over poll
    <braunr> the hurd being full of scalability issues, this one is
      clearly not a priority
    <nalaginrut> ok
    

    IRC, freenode, #hurd, 2013-09-26:

    <nalaginrut> if I want to have epoll/kqueue like things, where
      should it dwell? kernel or some libs?
    <braunr> libs
    <pinotree> userland
    <braunr> that would be a good project to work on, something i
      intended to do (so i can help) but it requires a lot of work
    <braunr> you basically need to add a way to explicitely install and
      remove polling requests (instead of the currently way that
      implicitely remove polling requests when select/poll returns)
    <braunr> while keeping the existing way working for some time
    <braunr> glibc implements select
    <braunr> the hurd io interface shows the select interface
    <braunr> servers such as pfinet/pflocal implement it
    <braunr> glibc implements the client-side of the call
    <nalaginrut> where's poll? since epoll just added edge-trigger in
      poll
    <braunr> both select and poll are implemented on top of the hurd io
      select call (which isn't exactly select)
    <braunr>
      http://git.sceen.net/hurd/hurd.git/plain/hurd/io.defs
    <braunr> this is the io interface
    <braunr>
      http://git.sceen.net/hurd/glibc.git/tree/hurd/hurdselect.c?h=tschwinge/Roger_Whittaker
    <braunr> this is the client side implementation
    

    IRC, freenode, #hurd, 2014-02-14:

    <desrt> also: do you know if hurd has a modern-day poll()
      replacement? ala epoll, kqueue, iocp, port_create(), etc?
    <pochu_> last thing I remember was that there was no epoll
      equivalent, but that was a few years ago :)
    <pochu_> braunr: ^
    * desrt is about to replace gmaincontext in glib with something
        more modern
    * desrt really very much wants not to have to write a poll()
        backend....
    <desrt> it seems that absolutely every system that i care about,
      except for hurd, has a new approach here :/
    <desrt> even illumos has solaris-style ports
    <azeem> desrt: I suggest you bring up the question on bug-hurd
    <azeem> the poll() system call there to satisfy POSIX, but there
      might be a better Hurd-specific thing you could use
    <azeem> is there*
    <desrt> that would be ideal
    <desrt> i have to assume that a system that passes to many messages
      has some other facilities :)
    <desrt> *so many
    <desrt> the question is if they work with fds....
    <desrt> bug-hurd doesn't seem like a good place to ask open-ended
      questions....
    <azeem> it's the main development lists, it's just old GNU naming
    <azeem> list*
    <desrt> k.  thanks.
    <azeem> bug-hurd@gnu.org is the address
    * desrt goes to bug... hurd
    <desrt> written.  thanks.
    <braunr> desrt: the hurd has only select/poll
    <braunr> it suffers from so many scalability issues there isn't
      much point providing one currently
    <braunr> we focus more on bug fixing and posix compliance right now
    <desrt> fair answer
    <braunr> you should want a poll-based backend
    <braunr> it's the most portable one, and doesn't suck as much as
      select
    <braunr> very easy to write
    <braunr> although, internally, our select/poll works just like a
      bare epoll
    <braunr> i.e. select requests are installed, the client waits for
      one or more messages, then uninstalls the requests
    

    IRC, freenode, #hurd, 2014-02-23:

    <desrt> brings me to another question i asked here recently that
      nobody had a great answer for: any plan to do kqueue?
    <braunr> not for now
    <braunr> i remember answering you about that
    <desrt> ah.  on IRC or the list?
    <braunr> that internally, our select/poll implementation works just
      like epoll
    <braunr> on irc
    <braunr> well "just like" is a bit far from the truth
    <desrt> well... poll() doesn't really work like epoll :p
    <braunr> internally, it does
    <braunr> even on linux
    <desrt> since both of us have to do the linear scan on the list
    <desrt> which is really the entire difference
    <braunr> that's the user interface part
    <braunr> i'm talking about the implementation
    <desrt> ya -- but it's the interface that makes it unscalable
    <braunr> i know
    <braunr> what i mean is
    <braunr> since the implementation already works like a more modern
      poll
    <braunr> we could in theory add such an interface
    <braunr> but epoll adds some complicated detail
    <desrt> you'll have to forgive me a bit -- i wasn't around from a
      time that i could imagine what a non-modern poll would look like
      inside of a kernel :)
    <braunr> what i mean with a modern poll is a scalable poll-like
      interface
    <braunr> epoll being the reference
    * desrt is not super-crazy about the epoll interface....
    <braunr> me neither
    <desrt> kevent() is amazing -- one syscall for everything you need
    <braunr> i don't know kqueue enough to talk about it
    <desrt> no need to do 100 epollctls when you have a whole batch of
      updates to do
    <desrt> there's two main differences
    <desrt> first is that instead of having a bunch of separate fds for
      things like inotify, timerfd, eventfd, signalfd, etc -- they're
      all built in as different 'filter' types
    <desrt> second is that instead of a separate epoll_ctl() call to
      update the list of monitored things, the kevent() call
      (epoll_wait() equivalent) takes two lists: one is the list of
      updates to make and the other is the list of events to
      return.... so you only do one syscall
    <braunr> well, again, that's the interface
    <braunr> internally, there still are updates and waits
    <braunr> and on a multiserver system like the hurd, this would mean
      one system call per update per fd
    <braunr> and then one per wait
    <desrt> on the implementation side, i think kqueue also has a nice
      feature: the kernel somehow has some magic that lets it post
      events to a userspace queue.... so if you're not making updates
      and you do a kevent() that would not block, you don't even enter
      the kernel
    <braunr> ok
    <desrt> hm.  that's an interesting point
    <desrt> "unix" as such is just another server for you guys, right?
    <braunr> no
    <braunr> that's a major difference between the hurd and other
      microkernel based systems
    <braunr> even multiserver ones like minix
    <braunr> we don't have a unix server
    <braunr> we don't have a vfs server or even an "fd server"
    <desrt> so mach knows about things like fds?
    <braunr> no
    <braunr> only glibc
    <desrt> oh.  weird!
    <braunr> yes
    <braunr> that's the hurd's magic :)
    <braunr> being so posix compliant despite how exotic it is
    <desrt> this starts to feel like msvcrt :p
    <braunr> maybe, i wouldn't know
    <braunr> windows is a hybrid after all
    <braunr> with multiple servers for its file system
    <braunr> so why not
    <braunr> anyway
    <desrt> so windows doesn't have fds in the kernel either... the C
      library runtime emulates them
    <braunr> mach has something close to file descriptors
    <desrt> which is fun when you get into dll hell -- sometimes you
      have multiple copies of the C library runtime in the same program
      -- and you have to take care not to use fds from one of them with
      th o ther one
    <braunr> yes ..
    <braunr> that, i knew :)
    <braunr> but back to the hurd
    <braunr> since fds are a glibc thing here, and because "files" can
      be implemented by multiple servers
    <braunr> (sockets actually most of the time with select/poll)
    <braunr> we have to make per fd requests
    <braunr> the implementation uses the "port set" kernel abstraction
    <desrt> right -- we could have different "fd" coming from different
      places
    <braunr> do you know what a mach port is ?
    <desrt> not even a little bit
    <braunr> hm
    <desrt> i think it's what a plane does when it goes really fast,
      right?
    <braunr> let's say it's a kernel message queue
    <braunr> no it's not a sonic boom
    <desrt> :)
    <braunr> ;p
    <braunr> so
    <braunr> ports are queues
    <desrt> (aside: i did briefly run into mach ports recently on macos
      where they modified their kqueue to support them...)
    <braunr> queues of RPC requests usually
    <desrt> (but i didn't use them or look into them at all)
    <braunr> they can be referenced through mach port names, which are
      integers much like file descriptors
    <braunr> they're also used for replies but, except for weird calls
      like select/poll, you don't need to know that :)
    <braunr> a port set is one object containing multiple ports
    <desrt> sounds like dbus :)
    <braunr> the point of a port set is to provide the ability to
      perform a single operation (wait for a message) on multiple ports
    <desrt> sounds like an epoll fd....
    <desrt> is the port set itself a port?
    <braunr> so, when a client calls select, it translates the list of
      fds into port names, creates reply ports for each of them, puts
      them into a port set, send one select request for each, and does
      one blocking wait on the port set
    <braunr> no, but you can wait for a message on a port set the same
      way you do on a port
    <braunr> and that's all it does
    <desrt> does that mean that you can you put a port set inside of
      another port set?
    <braunr> hm maybe
    <desrt> i guess in some way that doesn't actually make sense
    <braunr> i guess
    <desrt> because i assume that the message you sent to each port in
      your example is "tell me when you have some stuff"
    <braunr> yes
    <desrt> and you'd have to send an equivalent message to the port
      set.... and that just doesn't make sense
    <desrt> since it's not really a thing, per se
    <braunr> it would
    <braunr> insteaf of port -> port set, it would just be port -> port
      set -> port set
    <braunr> but we don't have any interface where an fd stands for a
      port set
    <braunr> what i'm trying to tell here is that
    <braunr> considering how it's done, you can easily see that there
      has to be non trivial communication
    <braunr> each with the cost of a system call
    <braunr> and not just any system call, a messaging one
    <braunr> mach is clearly not as good as l4 when it comes to that
    <desrt> hrmph
    <braunr> and the fact that most pollable fds are either unix or
      inet/inet6 sockets mean that there will be contention in the
      socket servers anyway
    <desrt> i've seen some of the crazy things you guys can do as a
      result of the way mach works and way that hurd uses it, in
      particular
    <desrt> normal users setting up little tcp/ip universes for
      themselves, and so on
    <braunr> yes :)
    <desrt> but i guess this all has a cost
    <braunr> the cost here comes more from the implementation than the
      added abstractions
    <braunr> mach provides async ipc, which can partially succeed
    <desrt> if i spin up a subhurd, it's using the same mach, right?
    <braunr> yes
    <desrt> that's neat
    <braunr> we tend to call them neighbour hurds because of that
    <braunr> i'm not sure it is
    <desrt> it puts it half way between linux containers and outright
      VMs
    <desrt> because you have a new kernel.... ish...
    <braunr> well, it is for the same reasons hypervisors are neat
    <desrt> but the kernel exists within this construct....
    <braunr> a new kernel ?
    <desrt> a new hurd
    <braunr> yes
    <desrt> but not a new mach
    <braunr> exactly
    <desrt> ya -- that's very cool
    <braunr> it's halfway between hypervisors and containers/jails
    <braunr> what matters is that we didn't need to write much code to
      make it work
    <braunr> and that the design naturally guarantees strong isolation
    <desrt> right.  that's what i'm getting at
    <braunr> unlike containers
    <desrt> it shows that the interaction between mach and these set of
      crazy things collectively referred to as the hurd is really
      proper
    <braunr> usually
    <braunr> sometimes i think it's not
    <braunr> but that's another story :)
    <desrt> don't worry -- you can fix it when you port to L4 ;)
    <braunr> eh, no :)
    <desrt> btw: is this fundamentally the same mach as darwin?
    <braunr> yes
    <desrt> so i guess there are multiple separate implementations of a
      standard set of interfaces?
    <braunr> ?
    * desrt has to assume that apple wouldn't be using GNU mach, for
        example...
    <braunr> no it's the same code base
    <braunr> they couldn't
    <braunr> but only because the forks have diverged a bit
    <desrt> ah
    <braunr> and they probably changed a lot of things in their virtual
      memory implementation
    <desrt> so i guess original mach was under some BSDish type thing
      and GNU mach forked from that and started adding GPL code?
    <braunr> something like that
    <desrt> makes sense
    <braunr> we have very few "non-standard" mach interfaces
    <braunr> but we now rely on them so we couldn't use another mach
      either
    <braunr> back to the select/poll stuff
    * desrt gets a lesson tonight :)
    <braunr> it costs, it's not scalable
    <braunr> but
    <braunr> we have scalability problems in our servers
    <braunr> they're old code, they use global locks
    <desrt> right.  this is the story i heard last time.
    <braunr> probably from me
    <braunr> poll works good enough for us right now
    <braunr> we're more interested in bug fixes than scalability
      currently
    <desrt> the reason this negative impacts me is because now i need
      to write a bunch more code ;p
    <braunr> i hope this changes but we still get weird errors that
      many applications don't expect and they react badly to those
    <braunr> well, poll really is the posix fallback
    <desrt> every other OS that we want to support has some sort of new
      scalable epoll-type interface or is Windows (which needs separate
      code anyway)
    <desrt> a very large number of them have kqueue... linux has
      epoll... solaris/illumos is the odd one out with this weird thing
      that's sort of like epoll
    <braunr> i would think you want a posix fallback for such a
      commonly used interface
    <braunr> hm
    <desrt> braunr: hurd is pretty much the only one that doesn't
      already have something better....
    <braunr> linux can be built without epoll
    <desrt> and the nice thing about all of these things is that every
      single one of them gives me an fd that can be polled when any
      event is ready
    <braunr> i don't see why anyone would do that, but it's a compile
      time option ;p
    <braunr> yes ...
    <braunr> we don't have xxxfd() :)
    <desrt> and we want to expose that fd on our API... so people can
      chain gmaincontext into other mainloops
    <braunr> that's expected
    <desrt> so for hurd this means that i will need to spin up a
      separate thread doing poll() and communicating back to the main
      thread when anything becomes ready
    <desrt> i was looking forward to not having to do that :)
    <braunr> it matches the unix "everything is a file" idea, and
      windows concept of "events"
    <braunr> i understand but again, it's a posix fallback
    <braunr> you probably want it anyway
    <desrt> probably
    <braunr> it could help new systems trying to be posix like
    <desrt> i honestly thought i'd get away with it, though
    <desrt> this is true...
    <desrt> CLOCK_MONOTONIC is an easy enough requirement to implement
      or fake.... "modern event polling framework" is another story...
    

    clock gettime.

    <braunr> yes, but again, we do have the underlying machinery to add
      it
    <desrt> i appreciate if your priorities are elsewhere ;)
    <braunr> it's just not worth the effort right now
    <braunr> although we do have performance and latency improvements
      in our patch queues currently
    <braunr> if our network stack gets replaced, it would become
      interesting
    <braunr> we need to improve posix compliance first
    <braunr> make more applications not choke on unecpected errors
    <braunr> and then we can think of improving scalability
    <desrt> +1 vote from me for implementing monotonic time :)
    <desrt> (and also pthread_condattr_setclock())
    <braunr> and we probably won't implement the epoll interface ;p
    <braunr> yes
    <desrt> it's worth noting that there is also a semi-widely
      available non-standard extension called
      pthread_cond_timedwait_relative_np that you could implement
      instead
    <desrt> it takes a (relative) timeout instead of an absolute one --
      we can use that if it's available
    <braunr> desrt: why would you want relative timeouts ?
    <desrt> braunr: if you're willing to take the calculations into
      your own hands and you don't have another way to base it on
      monotonic time it starts to look like a good alternative
    <desrt> and indeed, this is the case on android and macos at least
    <braunr> hm
    <desrt> not great as a user-facing API of course.... due to the
      spurious wakeup possibility and need to retry
    <braunr> so it's non standard alternative to a monotonic clock ?
    <desrt> no -- these systems have monotonic clocks
    <desrt> what they lack is pthread_condattr_setclock()
    <braunr> oh right
    <desrt> which is documented in POSIX but labelled as 'optional'
    <braunr> so relative is implicitely monotonic
    <desrt> yes
    <desrt> i imagine it would be the same 'relative' you get as the
      timeout you pass to poll()
    <desrt> since basing anything like this on wallclock time is
      absolutely insane
    <desrt> (which is exactly why we refuse to use wallclock time on
      our timed waits)
    <braunr> sure
    <braunr> i'm surprised clock_monotonic is even optional in posix
      2008
    <braunr> but i guess that's to give some transition margin for
      small embedded systems
    <desrt> when you think about it, CLOCK_REALTIME really ought to
      have been the optional feature
    <desrt> monotonic time is so utterly basic
    <braunr> yes
    <braunr> and that's how it's normally implemented
    <braunr> kernels provide a monotonic clock, and realtime is merely
      shifted from it
    

  • sys/eventfd.h

  • sys/inotify.h

  • sys/signalfd.h

  • sys/timerfd.h

  • timespec_get (74033a2507841cf077e31221de2481ff30b43d51, 87f51853ce3671f4ba9a9953de1fff952c5f7e52)

  • 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
      https://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)
    

  • getcontext/makecontext/setcontext/swapcontext

    Support for these functions within the Hurd threadvar environment has been added, but for multi-threaded applications (libpthread), it is a bit clunky: as a practical requirement, a thread's stack size always has to be equal to PTHREAD_STACK_DEFAULT, 2 MiB, and also has to be naturally aligned. The idea is still to get rid of Hurd threadvars and replace them with TLS.

    Aside from gccgo, the following packages might make use of these functions, searching on http://codesearch.debian.net/ for \b(get|set|make|swap)context\s*\( on 2013-05-18: boost1.49, chromium-browser, gtk-vnc, guile-1.8, iceape, icedove, iceweasel, libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim, and more.

    IRC, OFTC, #debian-hurd, 2013-09-08:

    <pinotree> oh, and even ruby2.0 suffers because of fixed-stack
      threads
    <youpi> yes, we definitely need to finish fixing it
    <youpi> my current work is in our glibc repo, youpi/tls-threadvar
    <pinotree> | *** makecontext: a stack at 0xbc000 with size 0x40000
      is not usable with threadvars
    <pinotree> all 8 failing tests with that
    <youpi> maybe we can hand-disable the use of contexts in ruby for
      now?
    <pinotree> gg0: ↑ :)
    <gg0> after the pseudo-patch i RFCed, i don't deserve to say
      anything else about that :)
    <pinotree> i mean, feel free to investigate and "fix" ruby2.0 as
      above :)
    <gg0> eh maybe i'd just be able to hand-disable failing
      thread-related _tests_ :)
    <gg0> i'm still hoping some real developer picks and actually fixes
      it, seems it's not enough interesting though
    <azeem> 21:37 < youpi> yes, we definitely need to finish fixing it
    <gg0> afaiu youpi is working on threadvars-tls migration, which
      would mean fixing them all. i just meant fixing ruby, which would
      mean having puppet btw
    <youpi> gg0: "actually fixing" means fixing threadvars-tls
      migration
    <youpi> "just fixing" ruby can be done by simply disabling context
      use in ruby
    

    IRC, OFTC, #debian-hurd, 2013-09-10:

    <gg0> this one fixes make test by disabling context and giving more
      time to timing related tests http://paste.debian.net/plain/37977/
    <gg0> make test-all is another story
    <youpi> gg0: AIUI, the sleep part should get fixed by the next
      glibc upload, which will include the getclk patch
    <youpi> but the disabling context part could be good to submit to
      the debian ruby package, mentioning that this is a workaround for
      now
    <gg0> unfortunately still not enough, test-all still fails
    <youpi> does it make the package not build?
    <gg0> test-all is the second part of what we call tests
    <gg0> they build and package (they produce all ruby packages),
      after that they run debian/run-test-suites.bash which is make
      test + make test-all
    <gg0> well after or during the build doesn't matter, it's their
      testsuite
    <gg0> ok just failed:
    <gg0> TestBug4409#test_bug4409 = Illegal instruction
    <gg0> make: *** [yes-test-all] Error 132
    <gg0> what to do with Illegal instruction?
    <gg0> just found 2 words that make everybody shut up :p
    <pinotree> same as above: debug it
    <teythoon> gg0: have you confirmed that this is reproducible? I've
      once had a process die with SIGILL and it was not and I figured
      it might have been a (qemu?) glitch
    <gg0> seems i'm running tests which are disabled on _all_ archs,
      better so
    <gg0> well, this should be reproducible. i just got it on a qemu, i
      could try to reproduce it on real hardware but as just said, i
      was testing tests disabled by maintainer so completely useless
    <teythoon> gg0: yeah, I'm running all my hurd instances on qemu/kvm
      as well, I meant did you get this twice in a row?
    <gg0> to be honest i got another illegal instruction months ago but
      don't recall doing what
    <gg0> nope not twice, i've commented it out. then run the remaining
      and then found out i should not have done what i was doing
    <gg0> but i could try to reproduce it
    <gg0> ok now i recall i got it another one few hours ago on real
      hardware, from logs:
    <gg0> TestIO#test_copy_stream_socket = Illegal instruction
    <gg0> teythoon: on real hardware though
    <gg0> and this is the one i should debug once it finishes, still
      running
    

    IRC, freenode, #hurd, 2013-09-11:

    <gg0_> ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind:
      Assertion `! __spin_lock_locked (&ss->critical_section_lock)'
      failed.
    <gg0_> and
    <gg0_> ../libpthread/sysdeps/mach/pt-thread-halt.c:51:
      __pthread_thread_halt: Unexpected error: (ipc/send) invalid
      destination port.
    <tschwinge> gg0_: Which libpthread source are these?  Stock Debian
      package?
    <gg0_> tschwinge: everything debian, ruby rebuilt with
      http://paste.debian.net/plain/38519/ which should disable
      *context
    

    IRC, OFTC, #debian-hurd, 2013-09-11:

    <gg0_> wrt ruby, i'd propose a patch that disables *context and
      comments out failed tests (a dozen). most of them are timing
      related, don't always fail
    <gg0_> if they failed gracefully, we could leave them enabled and
      just ignoring testsuite result, but most of them block testsuite
      run when fail
    <gg0_> anyone against? any better idea (and intention to implement
      it? :p)?
    <gg0_> youpi: is disabling some tests acceptable? ^
    <youpi> it'd be good to at least know what is failing
    <youpi> so as to know what impact hiding these failures will have
    <youpi> remember that hiding bugs usually means getting bitten by
      them even harder later :)
    <gg0_> many of them use pipes
    <gg0_> here the final list, see commented out ones
      http://paste.debian.net/plain/38426
    <gg0_> and as said some don't always fails
    <gg0_> test_copy_stream_socket uses a socket
    <youpi> note that we can still at least build packages with notest
    <youpi> at least to get the binaries uploaded
    <youpi> disabling *context should however really be done
    <youpi> and the pipe issues are concerning
    <youpi> I don't remember other pipe issues
    <youpi> so maybe it's a but in the ruby bindings
    <gg0_> i just remember they didn't die, then something unknown
      fixed it
    <youpi> I see something frightening in io.c
    <youpi> #if BSD_STDIO
    <youpi>          preserving_errno(fseeko(f, lseek(fileno(f),
      (off_t)0, SEEK_CUR), SEEK_SET));
    <youpi> #endif
    <youpi> this looks very much like a workaround for an odd thing in
      BSD
    <youpi> it happens that that gets enabled on hurd too, since
      __MACH__ is defined
    <youpi> you could try to drop these three lines, just to see
    <youpi> this is very probably very worth investigating, at any rate
    <youpi> even just test_gets_limit_extra_arg is a very simple test,
      that I fail to see why it should ever fail on hurd-i386
    <youpi> starting debugging it would be a matter of putting printfs
      in io.c, to check what gets called, with what parameters, etc.
    <youpi> just a matter of taking the time to do it, it's not very
      complex
    <gg0_> youpi: are you looking at 1.8? no BSD_STDIO here
    <youpi> yes, 1.8
    <gg0_> 1.9.3.448
    <gg0_> landed to sid few days ago
    <youpi> ah, I have 1.87
    <youpi> +.
    <gg0_> my favourites are TestIO#test_copy_stream_socket and
      TestIO#test_cross_thread_close_fd -> Illegal instruction
    <gg0_> TestIO#test_io_select_with_many_files sometimes Illegal
      instruction, sometimes ruby1.9.1:
      ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: Assertion
      `! __spin_lock_locked (&ss->critical_section_lock)' failed.
    

    thread-cancel c 55 hurd thread cancel assertion spin lock locked ss critical section lock?

    <gg0_> trying to debug illegal instruction
      http://paste.debian.net/plain/38585/
    <gg0_> (yes, i'm not even good at gdbing)
    <gg0_> any hint?
    <gg0_> oh found out there's an intree .gdbinit, that might
      complicate things
    

    IRC, OFTC, #debian-hurd, 2013-09-13:

    <gg0_> where should it be implemented MAP_STACK? plus, is it worth
      doing it considering migration to tls, wouldn't it be useless?
    <gg0_> sysdeps/mach/hurd/mmap.c i should reduce stupid questions
      frequency from daily to weekly basis
    

    IRC, OFTC, #debian-hurd, 2013-09-14:

    <gg0_> say i managed to mmap 0x200000-aligned memory
    <gg0_> now i get almost the same failed tests i get disabling
      *context
    <gg0_> that would mean they don't depend on threading
    

    IRC, freenode, #hurd, 2013-09-16:

    <gg0> i get many ../sysdeps/mach/hurd/jmp-unwind.c:53:
      _longjmp_unwind: Assertion `! __spin_lock_locked
      (&ss->critical_section_lock)' failed.
    <gg0> by running ruby testsuite, especially during test_read* tests
      http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L972
    <gg0> read/write operations with pipes
    <braunr> gg0: that's weird
    <braunr> gg0: debian glibc ?
    <gg0> braunr: yep, debian 2.17-92
    <gg0> sometimes assertion above, sometimes tests in question get
      stuck reading
    <gg0> it would be nice reproducing it w/o ruby
    <gg0> probably massive io on pipes could do the job
    <gg0> also more nice finding someone who finds it interesting to
      fix :p
    <gg0> ruby is rebuilt with http://paste.debian.net/plain/40755/, no
      *context
    <gg0> pipe function in tests above creates one thread for write,
      one for read
      http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
    <tschwinge> gg0: About the jmp-unwind assertion failure: is it be
      chance this issue:
      <http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html>?
      I didn't look in detail.
    <braunr> tschwinge: that's what i thought too about the assertion,
      which is why i find it strange
    <gg0> asserting it's not locked then locking it doesn't exclude
      race conditions
    

    IRC, OFTC, #debian-hurd, 2013-09-17:

    <gg0> youpi: i guess no one saw it anymore since
      tg-thread-cancel.diff patch
    <gg0> it =
      http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
    <gg0> this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though
    <gg0> another assertion to remove?
    <youpi> gg0: it's not exactly the same: in hurd_thread_cancel we
      hold no lock at all at the assertion point
    <youpi> in jmp-unwind.c, we do hold a lock
    <youpi> and the assertion might be actually true because all other
      threads are supposed to hold the first lock before taking the
      other one
    <youpi> you could check for that in other places
    <youpi> and maybe it's the other place which wouldhave to be fixed
    <youpi> also look for documentation which would say that
    

    IRC, freenode, #hurd, 2013-09-17:

    <braunr_> gg0: is that what we do ??
    <gg0> braunr: well, i was looking at
      http://sources.debian.net/src/eglibc/2.17-92/debian/patches/hurd-i386/tg-thread-cancel.diff
    <gg0> which afaics fixes
      http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
    <gg0> the one i get now is
      http://sources.debian.net/src/eglibc/2.17-92/sysdeps/mach/hurd/jmp-unwind.c#L53
    <gg0> 09:12 < youpi> gg0: it's not exactly the same: in
      hurd_thread_cancel we hold no lock at all at the assertion point
    <gg0> 09:13 < youpi> in jmp-unwind.c, we do hold a lock
    <gg0> 09:13 < youpi> and the assertion might be actually true
      because all other threads are supposed to hold the first lock
      before taking the other one
    <braunr> gg0: that assertion is normal
    <braunr> it says there is a deadlock
    <braunr> ss->critical_section_lock must be taken before ss->lock
    <gg0> you mean ss->lock before ss->critical_section_lock
    <braunr> no
    <gg0> ah ok got it
    <braunr> that's a bug
    <braunr> longjmp
    <braunr> ugh
    <braunr> you could make a pass through the various uses of those
      locks and check what the intended locking protocol should be
    <braunr> i inferred ss->critical_section_lock before ss->lock from
      hurd_thread_cancel
    <braunr> this might be wrong too but considering this function is
      used a lot, i doubt it
    <gg0> (no, i hadn't got it, i was looking at jmp-unwind.c where
      lock is before critical_section_lock)
    <gg0> could we get useful info from gdb'ing the assertion?
    <tschwinge> gg0: Only if you first get an understanding why it is
      happening, what you expect to happen instead/why it shall not
      happen/etc.  Then you can perhaps use GDB to verify that.
    <gg0> i can offer an irc interface if anyone is interested, it's
      ready, just to attach :)
    <gg0> this is the test
      http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L937
    <gg0> pipe function creates two threads
      http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
    <gg0> Attaching to pid 15552
    <gg0> [New Thread 15552.1]
    <gg0> [New Thread 15552.2]
    <gg0> (gdb) 
    

    IRC, freenode, #hurd, 2013-09-21:

    <youpi> gg0: it seems the assert (! __spin_lock_locked
      (&ss->critical_section_lock)); is bogus
    <youpi> but it'd be good to catch a call trace
    <youpi> well, it may not be bogus, in case that lock is only ever
      taken by the thread itself
    <youpi> in that case, inside longjmp_unwind we're not supposed to
      have it already
    <youpi> ok, that's what we had tried to discuss with Roland
    <youpi> it can happen when playing with thread cancelation
    <braunr> youpi: the assertion isn't exactly bogus
    <braunr> the lock ordering is
    <youpi> braunr: which one are you talking about?
    <youpi> the one in hurd_thread_cancel looks really wrong
    <youpi> and some parts of the code keep the critical section lock
      without ss->lock held, so I don't see how lock ordering can help
    

    IRC, OFTC, #debian-hurd, 2013-09-22:

    <gg0> how much does this patch suck on a scale from 1 to 10?
      http://paste.debian.net/plain/44810/
    <youpi> well, the stack allocation issue will go away once I get
      the threadvars away
    <youpi> I'm working on it right now
    <youpi> about the lib paths, it makes sense to add the gnu case,
      but i386-gnu shouldn't be put in the path
    <gg0> that's great
    <gg0> so seems the wrong moment for what i've already done
      ie. asking terceiro what he thinks about patch above :/
    <gg0> any distro-independent way to get libc.so and libm.so path?
    <gg0> ruby as last resource takes them from "ldd ruby"
    <pinotree> gg0: should work fine then
    <gg0> well it does. but gnu doesn't have a case so it hits default
      which is broken
      http://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/40235/entry/test/dl/test_base.rb
    <gg0> btw even linux and kfreebsd with debian multipath have broken
      cases but they don't hit default and get fixed by ldd later
    <pinotree> why it is broken? are arguments passed to that script?
    <gg0> i'm not sure about what propose. a broken case so it doesn't
      hit default like linux and kfbsd
    <gg0> yes they are :/
    <pinotree> and which ones are? who executes that script and which
      arguments does it pass to it?
    <gg0> other ruby scripts which have nothing to do with libc/libm
    <pinotree> well, if they pass arguments which should be the paths
      to libc and libm, they must be getting such paths, aren't they?
    <gg0> they don't. arguments are other ruby scripts, don't know why,
      maybe something else broken before
    <gg0> but that would mean that before there's a smarter path
      detection way, i doubt
    <pinotree> then add the case for hurd, but setting both libc and
      libm as nil
    <pinotree> so they will be fetched again
    <gg0> yep and would really ugly
    <gg0> +be
    <gg0> "please commit this one which wrongly sets paths."
    <gg0> an alternative would be removing default case
    <gg0> or pointing it out by proposing ldd in hurd case might make
      them review the whole detection
    <gg0> by setting correct paths like in patch above it wouldn't
      break a possible hurd-amd64, it would work due to ldd
    <youpi> gg0: that's why I said the patch is fine, but without the
      i386-gnu part of the path
    <youpi> just like it happens to be on linux & kfreebsd
    <gg0> i might take ldconfig -p output
    <gg0> to make it uselessly correct from start
    <gg0> http://bugs.ruby-lang.org/issues/8937
    <pinotree> note thar ruby 1.8 is EOL
    <pinotree> *that
    <gg0> -- If you're reporting a bug in both Ruby 1.9/2.0 and Ruby
      1.8: ruby-trunk, and write like "this bug can be reproduced in
      Ruby 1.8 as well." --
    <gg0> i suspect this one won't be the only one i'll file. unless
      upcoming youpi's tls and braunr's thread destruction patches fix
      all ruby tests
    <pinotree> did you check ruby2.0 too, btw?
    <gg0> switched to ruby2 few hours ago. i pointed out 2nd part of
      testsuite is not enabled, probably terceiro will enable it soon
    <gg0> by applying my patch above we'd completely fix current
      ruby2.0 build (yes because tests are not completely enabled)
    <pinotree> what you run those extra tests?
    <gg0>
      http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/run-test-suites.bash
    <gg0> make test + make test-all
    <gg0> (test-all is 2nd part)
    <gg0> many are problematic. i didn't finish yet to suppress them
      one-by-one. one i suppress, another one pops up
    <gg0> either get stuck or well known assertion
    <pinotree> check those that get stuck :)
    <gg0> which kind of check?
    <pinotree> "check" as in "debug"
    <gg0> btw i tested puppet few days ago (with ruby1.8), it seems to
      be working, at least at trasferring files from master
    <gg0> don't know about any advanced usage
    <pinotree> ruby 1.8 is going to die soon, so testing things against
      it is not totally useful
    <gg0> so you assume 1.8 is less broken than 1.9/2.0, right?
    <pinotree> no
    <gg0> i just can see it's been built without tests itself too
    <pinotree> erm no
    <gg0> well ok, if i can be wrong, i'll be wrong
    <gg0> i say that after a quick check time ago, might be wrong
    <pinotree> `getbuildlogs ruby1.8 last hurd-i386`, see the last
      build log
    <gg0> ah from pkg-kde-tools
    <gg0> i hate kde :)
    <pinotree> no?
    <gg0> no what?
    <pinotree> devscripts: /usr/bin/getbuildlog
    <gg0> pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs
    <pinotree> which is not what i said
    <gg0> wait that's what apt-file found
    <gg0> maybe i should update it
    <gg0> is it so recent?
    <pinotree> no
    <pinotree> i just added an 's' more at the end of the command, but
      typing getbu<tab> could have been helpful anyway...
    <gg0> yeah just got it
    <gg0> my fault not to have tried to run it before looking for it
    <pinotree> and btw, i don't see what hating kde has to do with
      tools developed by qt/kde debian packagers
    <gg0> j/k i simply don't use kde, never used and apt-file search
      told me it was from pkg-kde-tools
    <gg0> btw build log says "make test" fails, doesn't even start. and
      its failure doesn't block the build
    <pinotree> exactly
    <gg0> s/make test/make test-all/
    <gg0> "make test" (aka "1st part" above) doesn't run. i guess it's
      missing in packaging
    

    IRC, freenode, #hurd, 2013-09-22:

    <braunr> youpi: i mean the lock order where the assertion occurs is
      reserved compared to the one in hurd_thread_cancel
    <braunr> (and the one in hurd_thread_cancel is the same used in
      hurd condition-related functions)
    <youpi> "reserved" ?
    <braunr> reversed
    <braunr> :)
    <youpi> by "the assertion occurs", you mean gg0's spot?
    <braunr> yes
    <youpi> well , the assertion also happens in hurd_thread_cancel
    <braunr> it does oO
    <braunr> i didn't see that
    <youpi> but otherwise yes, it's completely bogus that we have both
      locking in different orders
    <youpi> could you submit the fix for jmp-unwind.c to upstream?
    <braunr> what fix ?
    <youpi> reversing the lock order
    <braunr> ah, simply that
    <youpi> (well, provided that hurd_thread_cancel is right)
    <braunr> that's what i suggested to gg0
    <braunr> to check where those locks are held and determine the
      right order
    

    IRC, OFTC, #debian-hurd, 2013-09-28:

    <gg0_> now we'd just need tls
    <gg0_> http://bugs.ruby-lang.org/issues/8937
    <gg0_> well, it would pass makecheck at least. makecheckall would
      keep hanging on threads/pipes tests i guess, unless tls/thread
      destruction patches fix them
    

    IRC, OFTC, #debian-hurd, 2013-10-05:

    <youpi> so what is missing for ruby2.0, only disabling use of
      context for now, no?
    <pinotree> i'm not tracking it closely, gg0_ is
    <gg0_> maybe terceiro would accept a patch which only disables
      *context, "maybe" because he rightly said changes must go
      upstream
    <gg0_> anyway with or without *context, many many tests in
      makecheckall fail by making it hang, first with and without
      assertion you removed, now they all simply hang
    <gg0_> youpi: what do we want to do? if you're about finishing tls
      migration (as i thought a couple of weeks ago), i won't propose
      anything upstream. otherwise i could but that will have to be
      reverted upstream once you finish
    <gg0_> about tests, current ruby2.0 doesn't run makecheckall, only
      makecheck which succeeds on hurd (w/o context)
    <gg0_> if anyone wants to give it a try:
      http://paste.debian.net/plain/51089
    <gg0_> first hunk makes makecheck (not makecheckall) succeed and
      has been upstreamed, not packaged yet
    <pinotree> what about makecheckall for ruby2.0?
    <gg0_> 16:58 < gg0_> anyway with or without *context, many many
      tests in makecheckall fail by making it hang, first with and
      without assertion you  removed, now they all simply hang
    <pinotree> i for a moment thought it as for 1.9.1, ok
    <pinotree> these hangs should be debugged, yes
    <gg0_> nope, tests behavior doesn't change between 1.9 and 2.0. i
      started suppressing tests onebyone on 2.0 as well and as happened
      on 1.9, i gave up cause there were too many
    <gg0_> yep a smart mind could start debugging them, starting from
      patch above pasted by a lazy one owner
    <gg0_> one problem is that one can't reproduce them by isolate
      them, they don't fail. start makecheckall then wait for one fail
    <gg0_> now after my stupid report, someone like pinotree could take
      it over, play with it for half an hour/an hour (which equals to
      half a gg0's year/a gg0's year
    <gg0_> )
    <gg0_> and fix them all
    
    
    <gg0_> 17:05 < gg0_> youpi: what do we want to do? if you're about
      finishing tls migration (as i thought a couple of weeks ago), i
      won't propose  anything upstream. otherwise i could but that will
      have to be reverted upstream once you finish
    <youpi> gg0_: I don't really know what to answer
    <youpi> that's why I didn't answer :)
    <gg0_> youpi: well then we could upstream context disable and keep
      it disabled even if you fix tls. ruby won't be as fast as it
      would be with context but i don't think anyone will complain
      about that. then once packaged, if terceiro doesn't enable
      makecheckall, we will have ruby2.0 in main
    <youpi> that can be a plan yes
    <gg0_> btw reverting it upstream should not be a problem eventually
    <youpi> sure, the thing is remembering to do it
    <gg0_> filed http://bugs.ruby-lang.org/issues/8990
    <gg0_> please don't fix tls too soon :)
    <gg0_> s/makecheck/maketest/g
    

    IRC, OFTC, #debian-hurd, 2013-10-08:

    <gg0_> ok. *context disabled http://bugs.ruby-lang.org/issues/8990
    
    
    <gg0> bt full of an attached stuck ruby test
      http://paste.debian.net/plain/53788/
    <gg0> anything useful?
    <youpi> uh, is that really all?
    <youpi> there's not much interesting unfortunately
    <youpi> did you run thread apply all bt full ?
    <youpi> (not just bt full)
    <gg0> no just bt full
    <gg0> http://paste.debian.net/plain/53790/
    <gg0> wait, there's a child
    <gg0> damn ctrl-c'ing while it was loading symbols made it crash :/
    <gg0> restarted testsuite
    <gg0> isn't it interesting that failed tests fail only if testsuite
      runs from beginning, whereas if run singularly, they succeed?
    <gg0> as it got out of whatever resources
    <gg0> youpi: http://paste.debian.net/plain/53798/
    <youpi> the interesting part is actually right at the top
    <youpi> it's indeed stuck in the critical section spinlock
    <youpi> question being what is keeping it
    <youpi> iirc I had already checked in the whole glibc code that all
      paths which lock  critical_section_lock actually release it in
      all cases, but maybe I have missed some
    <youpi> (I did find some missing paths, which I fixed)
    <gg0> i guess the same check you and braunr talk about in
      discussion just before this anchor
      https://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg
    <youpi> yes, but the issue we were discussing there is not what
      happens here
    <youpi> we would see another thread stuck in the other way roudn,
      otherwise
    <gg0> no way to get what is locking?
    <youpi> no, that's not recorded
    <gg0> and what about writing it somewhere right after getting the
      lock?
    <youpi> one will have to do that in all spots taking that lock
    <youpi> but yes, that's the usual approach
    <gg0> i would give it try but eglibc rebuild takes too much time,
      that conflicts with my laziness
    <gg0> i read even making locks timed would help
    

    IRC, OFTC, #debian-hurd, 2013-10-09:

    <gg0> so correct order would be:
    <gg0> __spin_lock (&ss->lock); // locks sigstate
    <gg0> __spin_lock (&ss->critical_section_lock);
    <gg0> [do critical stuff]
    <gg0> __spin_unlock (&ss->critical_section_lock);
    <gg0> __spin_unlock (&ss->lock);  // unlocks sigstate
    <gg0> ?
    
    
    <gg0> 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is
      waiting) https://bugs.ruby-lang.org/issues/9000
    <gg0> 21:46 < gg0> that means that if you take a 2.0 snapshot,
      it'll build fine on hurd (unless you introduce maketestall as in
      1.9, that would make it get stuck like 1.9)
    <gg0> 21:48 < terceiro> gg0: nice
    <gg0> 21:48 < terceiro> I will try to upload a snapshot as soon as
      I can
    <gg0> 21:52 < gg0> no problem. you might break my "conditional
      satisfaction" by adding maketestall. better if you do that on
      next+1 upload so we'll have at least one 2.0 built :)
    
    
    <gg0> would it be a problem granting me access to a porter box to
      rebuild eglibc+ruby2.0?
    <gg0> i'm already doing it on another vm but host often loses power
    <pinotree> you cannot install random stuff on a porterbox though
    <gg0> i know i'd just need build-deps of eglibc+ruby2.0 i guess
    <gg0> (already accessed to porter machines in the past, account
      lele, mips iirc)
    <gg0> ldap should remember that
    <gg0> don't want to disturb anyone else work btw. if it's not a
      problem, nice. otherwise no problem
    <pinotree> please send a request to admin@exodar.debian.net so it
      is not forgotten
    <gg0> following this one would be too "official"?
      http://dsa.debian.org/doc/guest-account/
    <pinotree> hurd is not a release architecture, so hurd machines are
      not managed by DSA
    <gg0> ok
    <pinotree> the general procedure outlines is ok though, just need
      to be sent to the address above
    <gg0> sent
    <gg0> (1st signed mail with mutt, in the worst case i've attached
      passphrase :))
    <youpi> gg0: could you send me an ssh key?
    <pinotree> no alioth account?
    <youpi> yes, but EPERM
    <gg0> youpi: sent to youpi@
    <youpi> youpi@ ?
    <gg0> (... which doesn't exist :/)
    <gg0> sthibault@
    <youpi> please test gg0-guest@exodar.debian.net ?
    <youpi> (I'd rather not adduser the ldap name, who knows what might
      happen when you get your DD account)
    <gg0> i'm in. thanks
    <youpi> you're welcome
    <gg0> ldap users need to be adduser'ed?
    <youpi> I'm not getting your ldap user account from ud-replicate,
      at least
    <gg0> (btw i never planned to apply nm, i'd be honoured but i
      simply think not to deserve it)
    <youpi> never say never ;)
    <gg0> bah i like failing. that would be a success. i can't :)
    <gg0> gg0-guest@exodar:~$ dchroot   
    <gg0> E: Access not authorised
    <gg0> I: You do not have permission to access the schroot service.
    <gg0> I: This failure will be reported.
    <youpi> ah, right, iirc I need to add you somewhere
    <youpi> gg0: please retry?
    <gg0> works
    <youpi> good
    <gg0> are there already eglibc+ruby2.0 build-deps?
    <youpi> yes
    <gg0> oh that means i should do something myself now :)
    <youpi> yep, that had to happen at some point :)
    <gg0> my laziness thanks: "at some point" is better than "now" :)
    

    IRC, freenode, #hurd, 2013-10-10:

    <gg0> ok just reproduced the
      former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits
    <braunr> 20:37 < braunr> gg0: does ruby create and destroy threads
      ?
    <gg0> no idea
    <gg0> braunr: days ago you and youpi talked about locking order
      (just before this anchor
      https://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg)
    <braunr> oh right
    <gg0> <youpi> could you submit the fix for jmp-unwind.c to
      upstream?
    <braunr> it didn't made it in the todo list
    <gg0> so correct order is in hurd_thread_cancel, right?
    <braunr> sorry about that
    <braunr> we need to make a pass to make sure it is
    <gg0> that means locking first ss->critical_section_lock _then_
      ss->lock
    <gg0> correct?
    <braunr> but considering how critical hurd_thread_cancel is, i
      expect so
    
    
    <gg0> i get the same deadlock by swapping locks
    <gg0> braunr: youpi: fyi ^
    <gg0> 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and
      destroy threads ?
    <gg0> how could i check it?
    <braunr> gg0: ps -eflw
    <youpi> gg0: that's not surprising, since in the b acktrace you
      posted there isn't another thread locked in the other order
    <youpi> so it's really that somehow the thread is already in
      critical sesction
    <braunr> youpi: you mean there is ?
    <braunr> ah, it's not the same bug
    <youpi> no, in what he posted, no other thread is stuck 
    <youpi> so it's not a locking order
    <youpi> just that the critical section is actually busy
    <gg0> youpi: ack
    <gg0> braunr: what's the other bug? ext2fs one?
    <braunr> gg0: idk
    <gg0> braunr: thanks. doesn't show threads (found -T for that) but
      at least doesn't limit columns number if piped (thanks to -w)
    <braunr> it does
    <braunr> there is a TH column
    <gg0> ok thread count. -T gives more info
    

    IRC, freenode, #hurd, 2013-10-24:

    <youpi> ruby2.0 builds fine with the to-be-uploaded libc btw
    <gg0> youpi: without d-ports patches? surprise me :)
    <youpi> gg0: plain main archive source
    <gg0> you did it. surprised
    <gg0> ah ok you just pushed your tls. great!
    <braunr> tls will fix a lot of things
    

    IRC, OFTC, #debian-hurd, 2013-11-03:

    <youpi> gg0: 
    <youpi> #252 test_fork.rb:30:in `<top (required)>': core dumped
      [ruby-core:28924]
    <youpi> FAIL 1/949 tests failed
    <youpi> with the to-be-uploaded glibc
    <gg0> why does it coredump?
    <gg0> that's the test i had workarounded by increasing sleep from 1
      to 3 but i don't recall it coredump'ed
    <gg0> *recall if
    <gg0> "sleep 1" at bootstraptest/test_fork.rb:33
    <youpi> how can I run the test alone?
    

    IRC, OFTC, #debian-hurd, 2013-11-04:

    <youpi> gg0: ^
    <gg0> it should not take much
    <gg0> run $ make OPTS=-v test
    <gg0> found out how to minimize
    <gg0> mkdir _youpi && cp bootstraptest/{runner,test_fork}.rb _youpi
    <gg0> then run $ ./miniruby -I./lib -I. -I.ext/common
      ./tool/runruby.rb --extout=.ext  -- --disable-gems
      "./_youpi/runner.rb" --ruby="ruby2.0 -I./lib" -q -v
    <gg0> youpi: that should work
    <youpi> #1 test_fork.rb:1:in `<top (required)>': No such file or
      directory - /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
      -I/usr/src/ruby1.9.1-1.9.3.448/lib -W0  bootstraptest.tmp.rb
      [ruby-dev:32404]
    <gg0> seems it can't find /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
    <youpi> well it's ruby1.9.1 indeed :)
    <youpi> ok, got core
    <gg0> replace 2.0 with 1.9, check what you have in rootdir
    <gg0> k
    <youpi> Mmm, no, there's no core file
    <gg0> does stupidly increasing sleep time work?
    <youpi> nope
    <gg0> without *context it runs "make test" fine. real problems come
      later with "make test-all"
    <gg0> wrt test_fork, is correspondence between signals correct? i
      recall i read something about USR1 not implemented
    <youpi> USR1 is implemented, it's SIGRT which is not implemented
    <gg0> my next wild guess is that that has something to do with
      atfork, whatever that means
    <gg0> it makes 2 forks: one sleeps for 1 sec then kills -USR1
      itself, the second traps USR1 in getting current time. in the
      meanwhile parent sleeps for 2 secs
    

    IRC, OFTC, #debian-hurd, 2013-11-07:

    <gg0> ruby2.0 just built on unstable
    

    IRC, OFTC, #debian-hurd, 2013-11-09:

    <gg0> youpi: just found out a more "official" way to run one test
      only
      http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/README.porters;h=94aff7dd3ecd9f748498f2e285b4a4313b4b8f36;hb=HEAD
    <gg0> btw still getting coredumps?
    

    IRC, OFTC, #debian-hurd, 2013-11-13:

    <gg0> wrt the other test test_fork i suppose you made it not to
      segfault anymore, it simply does fail
    <youpi> I haven't taken any particular care
    <youpi> didn't have any time to deal with it
    

    IRC, OFTC, #debian-hurd, 2013-11-14:

    <gg0> btw patches to disable *context have been backported to 1.9
      as well so next 1.9 point release should have *context disabled
    <gg0> as 2.0 have
    <gg0> *has
    <gg0> i guess you'd like to get them reverted now
    <gg0> youpi: ^
    <youpi> after testing that *context work, yes
    

  • sigaltstack

    IRC, freenode, #hurd, 2013-10-09:

    <gnu_srs1> Hi, is sigaltstack() really supported, even if it is
      defined as well as SA_ONSTACK?
    <braunr> probably not
    <braunr> well,
    <braunr> i don't know actually, mistaking with something else
    <braunr> it may be supported
    <pinotree> iirc no
    <gnu_srs1> pinotree: are you sure?
    <pinotree> this is what i remember
    <pinotree> if you want to be sure that $foo works, just do the
      usual way: test it yourself
    <gnu_srs1> found it: hurd/TODO: *** does sigaltstack/sigstack
      really work? -- NO
    <pinotree> well TODO is old and there were signal-related patches
      by jk in the meanwhile, although i don't think they would have
      changed this lack
    <pinotree> in any case, test it
    <gnu_srs1> anybody fluent in assembly? Looks like this code
      destroys the stack: http://paste.debian.net/54331/
    <braunr> gnu_srs1: why would it ?
    <braunr> it does something special with the stack pointer but it
      just looks like it aligns it to 16 bytes, maybe because of sse2
      restrictions (recent gcc align the stack already anyway)
    <gnu_srs1> Well, in that case it is the called function:
      http://paste.debian.net/54341/
    <braunr> how do you know there is a problem with the stack in the
      first place ?
    <gnu_srs1> tracing up to here, everything is OK. then esp and ebp
      are destroyed.
    <gnu_srs1> and single stepping goes backward until it segfaults
    <braunr> "destroyed" ?
    <gnu_srs1> zero if I remember correctly now. the x86 version built
      for is i586, should that be changed to i486?
    <braunr> this shouldn't change anything
    <braunr> and they shouldn't get to 0
    <braunr> use gdb to determine exactly which instruction resets the
      stack pointer
    <gnu_srs1> how to step into the assembly part? using 's' steps
      through the function since no line information:
    <gnu_srs1> Single stepping until exit from function
      wine_call_on_stack,
    <gnu_srs1> which has no line number information.
    <braunr> gnu_srs1: use break on the address
    <gnu_srs1> how do i get the address of where the assembly starts?
    

  • recvmmsg/sendmmsg (t/sendmmsg)

    From id:"20120625233206.C000A2C06F@topped-with-meat.com", Roland McGrath: They are generally useful interfaces and there is nothing intrinsically Linuxoid about them. At least when not given a timeout, they could be implemented in terms of sendmsg/recvmsg. So perhaps we ought to have a sysdeps/posix implementation that the Hurd would use instead of stubs (and folks can consider adding new RPCs). Then perhaps the Linux fallback case should be that instead of stubs, too.

  • SOCK_CLOEXEC

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

    <gnu_srs1> Do we support  accept4  with the SOCK_CLOEXEC flag?
    <gnu_srs1> According to the code in  sysdeps/mach/hurd/accept4.c
      that case is not covered 
    <gnu_srs1> (only O_NONBLOCK, not SOCK_NONBLOCK??))
    <pinotree> gnu_srs1: we do
    <pinotree> but only for accept4, not for socket and socketpair
    <gnu_srs1> pinotree: cannot find the case for O_CLOEXEC covered in
      __libc_accept4()
    <pinotree> gnu_srs1: no, you need SOCK_*
    <gnu_srs1> The only code for accept4() is in sysdeps/mach/hurd/ and
      it uses O_* for flags ?
    <pinotree>   flags = sock_to_o_flags (flags);
    <pinotree> tried checking it?
    <gnu_srs1> Aha, tks:-D
    <pinotree> and you don't need an explicit case of O_CLOEXEC, since
      it is handled in other ways
    

    id:"1378154151.21738.15.camel@G3620.my.own.domain".

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

    <gnu_srs> any ideas about the SOCK_CLOEXEC issue?
    <pinotree> didn't i tell already about it?
    <gnu_srs> I did not find any hurd related code in tschwinges
      branches.
    <pinotree> you didn't check deep then...
    <gnu_srs> so why does socket/socketpair not return ENOSYS then?
    <pinotree> why should it, since they are implemented?
    <braunr> ...
    <gnu_srs> for socket/socketpair?
    <braunr> gnu_srs: enosys means no system call
    <gnu_srs> s/ENOSYS/EINVAL/
    <gnu_srs> see the mail to the bug-hurd/debian-hurd ML for more info
    <gnu_srs> and tschwinges reply
    <pinotree> which is what i knew already?
    <gnu_srs> pinotree: please reply on the mailing list on the EINVAL
      vs EPROTOTYPE issue to clarify things
    <pinotree> gnu_srs:
      https://sourceware.org/ml/libc-alpha/2013-02/msg00092.html
    <pinotree> gnu_srs: things were clear already...
    <gnu_srs> pinotree: I've read that patch and still pflocal/pf.c
      returns EPROTOTYPE not changed by the __socket wrapper in eglibc
    <pinotree> gnu_srs: what about realizing SOCK_CLOEXEC and friends
      are NOT posix?
    <gnu_srs> since socket/socketpair does not return EINVAL the dbus
      code has to be patched then?
    <pinotree> pflocal should never ever get such flags mixed to the
      protocol, so any invalid value of protocol correctly returns
      EPROTOTYPE
    <gnu_srs> this is the question I need answered: Which way to go?
    <pinotree> all of them
    <gnu_srs> ?
    <pinotree> - applications should not assume that because you have
      accept4 (which is not posix) then SOCK_CLOEXEC and SOCK_NONBLOCK
      (flags for it) are usable to socket and socketpair
    <pinotree> - glibc should (as the idea of my patch) handle
      implementations providing SOCK_* but not supporting them for
      socket/socketpair
    <pinotree> - finally the hurd part of glibc could implement them
    <gnu_srs> to conclude: should I send a bug report for dbus then?
    <gnu_srs> pinotree: yes or no?
    <pinotree> gnu_srs: *shrug* i wrote it above, so an *upstream*
      report (not a debian one)
    

    IRC, freenode, #hurd, 2013-09-06:

    <gnu_srs> I've found another error code issue, now in  glib2.0 (and
      dbus). Are you really sure the error code 
    <gnu_srs> for protocol of pflocal/pf.c should be
      EPROTONOSUPPORT. The code expects EINVAL for a protocol with
    <gnu_srs>  SOCK_CLOEXEC, which is a flag. Maybe pf.c should add
      this case and return EINVAL instead of 
    <gnu_srs> submitting bug reports upstream. Yes, I know this is not
      POSIX, but it is defined for Hurd too, 
    <gnu_srs> currently only supported for accept4, not socket or
      socketpair. 
    <pinotree> gnu_srs: no, and i explained already why it is wrong
      this way
    <pinotree> pflocal shouldn't even get such flags
    <pinotree> (pflocal or any other server implementing socket_create)
    <gnu_srs> (20:19:35) pinotree: pflocal shouldn't even get such
      flags
    <gnu_srs> then the glibc wrapper code is missing to catch this
      flag:(
    <gnu_srs> youpi: ?
    <pinotree> gnu_srs: because, as told many times, socket and
      socketpair do not support such flags
    <pinotree> given they don't do, they filter nothing
    <pinotree> and no, you need to file bugs upstream, since having
      SOCK_* and accept4 does not imply at all that socket and
      socketpair support them
    

    IRC, freenode, #hurd, 2013-09-07:

    <gnu_srs> A correction from yesterdays discussion:
      s/EPROTONOSUPPORT/EPROTOTYPE
    

    IRC, freenode, #hurd, 2013-09-10:

    <gnu_srs> for dbus2.0 I found out that the third SOCK_CLOEXEC case
      needs a patch too (more working tests),
    <gnu_srs> the updated patch is at http://paste.debian.net/37948/ if
      you have the time, otherwise I'll do it.
    <pinotree> gnu_srs: which is what i wrote in my bug report...
    <gnu_srs> Yes you wrote that, but the patch is not updated yet?
    <pinotree> it refers to a different socket access, recently added,
      which is not used by default
    <gnu_srs> I got two more tests running when adding that patch:-/
    <pinotree> tests of what?
    <gnu_srs>  run-test.sh and run-test-systemserver.sh:P
    <pinotree> tests of what?
    <pinotree> i don't have the universal knowledge of the files in all
      the sources
    <gnu_srs> dbus-1.6.14/test/name-test/*
    

    id:"523A3D6C.2030200@gmx.de".

    IRC, OFTC, #debian-hurd, 2013-09-19:

    <pinotree> tschwinge: ehm, regarding the SOCK_* patches for
      socket/socketpair, didn't we talk about them when i worked on
      eglibc 2.17?
    

  • mlock, munlock, mlockall, munlockall

    IRC, freenode, #hurd, 2014-01-09:

    <gnu_srs> Hi, is mlock, mlockall et al implemented?
    <braunr> i doubt it
    <braunr> mlock could be, but mlockall only partially
    

  • glibc IOCTLs

  • Support for $ORIGIN in the dynamic linker, ld.so

    IRC, freenode, #hurd, 2014-02-23:

    <sjamaan>
      https://www.gnu.org/software/hurd/user/jkoenig/java/report.html
      says $ORIGIN patches have been added to Hurd.  Have those hit the
      mainline codebase?
    

    java, report.

    <sjamaan> It doesn't seem to work here, but perhaps I'm missing
      something (I'm using the prebuilt Debian/Hurd 2014-02-11 VM
      image)
    <sjamaan> objdump -x says the value of RPATH is $ORIGIN
    <sjamaan> But it doesn't load a library I placed in the same dir as
      the binary
    <braunr> sjamaan: i'm not sure
    <braunr> sjamaan: what are you trying to do ?
    

    IRC, freenode, #hurd, 2014-02-24:

    <sjamaan> braunr: I am working on a release of the CHICKEN Scheme
      compiler. Its test suite is currently failing on the stand-alone
      deployment tests.  Either it should work and use $ORIGIN, or the
      test should be disabled, saying Hurd is not supported for
      stand-alone deployment-directories
    <sjamaan> braunr: The basic idea is to be able to create "appdirs"
      like on OS X or PC-BSD, containing all the dependencies a program
      needs, which can then simply be untarred
    <braunr> sjamaan: ok so you do need $ORIGIN
    <sjamaan> yeah
    <sjamaan> iiuc, so does Java.  Does Java work on Hurd?
    <braunr> we had packages at the time jkoenig worked on it
    <braunr> integration of patches may have been incomplete, i wasn't
      there at the time and i'm not sure
    <sjamaan> So it's safest to claim it's unsupported, for now?
    <braunr> yes
    <sjamaan> Thank you, I'll do that and revisit it later
    

  • mig_reply_setup

    IRC, freenode, #hurd, 2014-02-24:

    <teythoon> braunr: neither hurd, gnu mach or glibc provides
      mig_reply_setup
    <teythoon> i want to provide this function, where should i put it ?
    <teythoon> i found some mach source that put it in libmach afaic
    <teythoon>
      ftp://ftp.sra.co.jp/.a/pub/os/mach/extracted/mach3/mk/user/libmach/mig_reply_setup.c
    <braunr> teythoon: what does it do ?
    <teythoon> braunr: not much, it just initializes the reply message
    <teythoon> libports does this as well, in the
      ports_manage_port_operations* functions
    <braunr> teythoon: is it a new function you're adding ?
    <teythoon> braunr: yes
    <teythoon> braunr: glibc has a declaration for it, but no
      implementation
    <braunr> teythoon: i think it should be in glibc
    <braunr> maybe in mach/
    

  • POSIX file record locking

  • execve with relative paths

    GNU Savannah bug #28934, pochu, id:"4BFA500A.7030502@gmail.com".

    IRC, freenode, #hurd, 2014-03-05:

    <teythoon> youpi: what about the exec_filename patch series? [...]
    <youpi> Roland was disagreeing with it
    

  • mount/umount

    IRC, freenode, #hurd, 2014-03-01:

    <gnu_srs1> Hi, how to handle packages depending on mount.h, et al?
      On Hurd mount/umount is supplied by hurd is not in libc?
    <azeem> gnu_srs1: mount or mount.h?
    <gnu_srs1> mount.h et al
    <gnu_srs1> man 2 mount
    <azeem> what is the question then?
    <gnu_srs1> some packages expect the mount 2 functionality
      available, not by the external command mount/umonut
    <gnu_srs1> umount*
    <gnu_srs1> azeem: one example is fuse
    <teythoon> gnu_srs1: that is correct
    <teythoon> gnu_srs1: i put a small hacks entry in the list about
      moving the mount/umount functionality from our utilities to the
      libc
    

  • POSIX Timers

    timer_create, timer_delete, clock gettime, and so on.

  • fd_to_filename

    See translate FD or port to file name.

  For specific packages:

  • octave

• Create t/cleanup_kernel-features.h.

• Secure file descriptor handling.

• 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.
  

• IRC, OFTC, #debian-hurd, 2013-08-16:

  <pinotree> http://paste.debian.net/25934/ ← _hurd_thread_sigstate calls
    malloc, boom
  

• conformtest

  IRC, OFTC, #debian-hurd, 2013-09-22:

  <youpi> btw, I noticed that glibc has a head conformance test which we
    happily fail quite a bit :)
  <youpi> it's not so awful, we don't have twice as many failures as
    linux, but not so far
  <pinotree> youpi: do you mean "header" for "head", right?
  <youpi> err, where ? :)
  <pinotree> <youpi> btw, I noticed that glibc has a head conformance
    test which we happily fail quite a bit :)
  <youpi> ah, yes
  <pinotree> noticed that too
  <youpi> I had a quick look at the POSIX part, some things are probably
    not too hard to change (e.g. exposing pthread_kill in signal.h)
  <youpi> others will by quite hard to fix (short type instead of int
    type for some flock structure field)
  <youpi> s/by/be/
  

• truncate/ftruncate

  Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603, glibc still to be done?

  IRC, freenode, #hurd, 2013-10-01:

  <pinotree> libdiskfs/node-drop.c:      assert (np->dn_stat.st_size == 0); ←
    this one?
  <pinotree> iirc you constantly get that when building ustr
  <braunr> is ustr a package ?
  <pinotree> yes
  <pinotree> iirc the ustr tests are mostly disk-intensive
  

  IRC, freenode, #hurd, 2013-10-02:

  <braunr> i've traced the problem up to truncate
  <braunr> which gets a negative size
  <braunr> shouldn't take long to find out where it comes from now
  <pinotree> it seems our truncate doesn't handle negative values well though
  <braunr>        EINVAL The argument length is negative or larger than the
    maximum file size.
  <braunr> i still have to see whether it comes from the user (unlikely) or
    if it's an internal inconsistency
  <braunr> i suspect some code wrongly handles vm_map failures
  <braunr> leading to that inconsistency
  <braunr> pinotree: looks like glibc doesn't check for length >= 0
  <pinotree> yeah
  <braunr> servers should do it nonetheless
  <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both?
  <braunr> it appears a client does the truncate
  <braunr> i'd say both
  <braunr> can you take the glibc part ? :)
  <pinotree> i was going to do the hurd part... :p
  <pinotree> ok, i'll pick libc
  <braunr> well i'm doing it already
  <braunr> i want to write a test case first
  <braunr> to make sure that's the problem
  <pinotree> already on the hurd part, you mean?
  <braunr> yes
  <pinotree> ok
  <braunr> ok looks like it
  <braunr> i can't reproduce the assertion but it does make ext2fs freeze
  <braunr> pinotree: https://darnassus.sceen.net/~rbraun/test_ftruncate.c
  <pinotree> merci
  <braunr> pinotree: ustr builds
  <pinotree> wow
  <braunr> the client code (ustr) seems to perform a ftruncate with size
    ((size_t)-1) whereas lengths are signed ..
  <braunr> i'll check other libraries and send a patch soon
  

  IRC, freenode, #hurd, 2013-10-03:

  <braunr> youpi: i've committed a fix to hurd that checks for negative sizes
    when truncating files
  <braunr> this allows building the ustr package without making ext2fs choke
    on an assertion
  <braunr> pinotree is preparing a patch for glibc
  <braunr> see truncate/ftruncate
  <braunr> with an off_t size parameter, which can be negative
  <braunr>        EINVAL The argument length is negative or larger than the
    maximum file size.
  <braunr> hurd servers were not conforming to that before my change
  

• t/ptrmangle: PTR_MANGLE/PTR_DEMANGLE

  • https://sourceware.org/glibc/wiki/PointerEncryption

  • See also t/tls.

  • b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8 ARM: Add pointer encryption support. may help to find all the places that need to be touched when adding support.

• 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?
  • 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)«.

  • ba384f6ed9275f3966505f2375b56d169e3dc588, 0409959c86f6840510851a851a1588677a2e537b, e57b0c6100e63bfd816ae59339452eafc81f1d3a C++11 thread_local destructors support. Anything needed to be done in our libpthread and configured for us in GCC? Probably need to replicate the nptl/pthread_create.c change, and fix stdlib/Makefile:$(objpfx)tst-tls-atexit.

    +++ include/link.h
    @@ -302,6 +302,9 @@ struct link_map
    +    /* Number of thread_local objects constructed by this DSO.  */
    +    size_t l_tls_dtor_count;
    
    
    +++ include/stdlib.h
    @@ -100,6 +100,11 @@ extern int __cxa_atexit (void (*func) (void *), void *arg, void *d);
    +extern int __cxa_thread_atexit_impl (void (*func) (void *), void *arg,
    +                                    void *d);
    +extern void __call_tls_dtors (void);
    +libc_hidden_proto (__call_tls_dtors);
    
    
    +++ nptl/pthread_create.c
    @@ -311,6 +311,9 @@ start_thread (void *arg)
     [after the thread function returns]
    +  /* Call destructors for the thread_local TLS variables.  */
    +  __call_tls_dtors ();
    
    
    +++ stdlib/Makefile
    +$(objpfx)tst-tls-atexit = $(common-objpfx)nptl/libpthread.so \
    +                        $(common-objpfx)dlfcn/libdl.so
    
    
    +++ stdlib/cxa_thread_atexit_impl.c
    
    
    +++ stdlib/exit.c
     __run_exit_handlers (int status, struct exit_function_list **listp,
                         bool run_list_atexit)
     {
    +  /* First, call the TLS destructors.  */
    +  __call_tls_dtors ();
    
    
    +gcc-4.7 tst-tls-atexit.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parenth
    +gcc-4.7 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit   [...]/tschwinge/Roger_Whittaker.build/nptl/lib
    +gcc-4.7: error: [...]/tschwinge/Roger_Whittaker.build/nptl/libpthread.so: No such file or directory
    +make[2]: *** [[...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit] Error 1
    +gcc-4.7 tst-tls-atexit-lib.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-par
    +tst-tls-atexit-lib.c: In function 'do_foo':
    +tst-tls-atexit-lib.c:35:3: warning: implicit declaration of function '__cxa_thread_atexit_impl' [-Wimplicit-function-declaration]
    

  • a600e5cef53e10147932d910cdb2fdfc62afae4e Consolidate Linux and POSIX libc_fatal code. -- is backtrace_and_maps specific to Linux?

    IRC, freenode, #hurd, 2014-02-06:

    <braunr> why wouldn't glibc double free detection code also print
      the backtrace on hurd ?
    <youpi> I don't see any reason why
    <youpi> except missing telling glibc that it's essentially like on
      linux
    

  • 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff Use __ehdr_start, if available, as fallback for AT_PHDR. -- once we require Binutils 2.23, can we simplify glibc's process startup (initialization of _dl_phdr and _dl_phnum)? As these are only used for [!SHARED], can we completely remove them (that is, the phdr and phdrsz members) from hurd_startup_data, and simplify exec startup get info, or do we still require these for the [SHARED] case?

  • fab7ce3f5b4060bf62659e8b58529de4156b5a2f Link extra-libs consistently with libc and ld.so. Alright for us? Probably have to adjust [libpthread]/Makefile.
  • b8c61b4b1d6afb69190169764c1b141f4659e48b Remove trailing whitespace from mach/*.sub. Update mach/Makefile: generated mach/errsystems.c is no longer checked in as of 66e3dda448406399136e6f144a1b46679d5b2613. Rule had been disabled in 421f82e5cc8f81ab003247d771bcecbad799be85, then re-enabled in 8e3cc80f6d4f69ce003c82d3561ac324692792ad, but comment not removed.
  • [low] 61dd6208fb1e59a423b6dfa712a3c896c34b2590 New API to set default thread attributes. Implement in libpthread (open issue libpthread)?
  • [high] e4608715e6e1dd2adc91982fd151d5ba4f761d69 CVE-2013-2207, BZ #15755: Disable pt_chown. -- <a href="http://mid.mail-archive.com/51E8D4C1%2E9000705%40redhat%2Ecom">id:"51E8D4C1.9000705@redhat.com"</a>; do we need it (--enable-pt_chown`)? cdfc721b8d2d5079325ea9f0beb5673d72b4cdd0.
  • 91ce40854d0b7f865cf5024ef95a8026b76096f3 CVE-2013-4237, BZ #14699: Buffer overflow in readdir_r -- id:"519220C7.6050705@redhat.com"; do we need corresponding changes to Hurd sysdep files?
  • 8cc3269f95fa7faa8f448d741f68cbc40efbf4ee Flesh out 4.4 bits/socket.h with SOCK_CLOEXEC, SOCK_NONBLOCK., e041fb8b6557882b6710a655a97bbf3541b56b54 Replace generic bits/socket.h with 4.4 file. -- sysdeps/mach/hurd/bits/socket.h differs from the generic bits/socket.h now only in the values of SOCK CLOEXEC and SOCK_NONBLOCK. If possible (no conflicts), would it make sense to transition to the latter file, continuing to accept the former values as deprecated for some time?
  • [high] 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 Fix unsafe compiler optimization -- have to revert, see sourceware [BZ #15605]. For analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49.
  • 6c82a2f8d7c8e21e39237225c819f182ae438db3 Coordinate IPv6 definitions for Linux and glibc -- alright for us?
  • c61b4d41c9647a54a329aa021341c0eb032b793e POINTER_CHK_GUARD -- see t/tls.
  • 5f855e3598a576c35e54623a13b256f3e87fcd4d Fix erroneous (and circular) implied pattern rule for linkobj/libc.so. -- alright for us?
  • [high] 7b7bab1391a3b16fff7e325e2c8a36b68eacba90 [Hurd] Add fork hooks for pthread_atfork -- is that from a topic branch that can then be annihilated? Verify emails. Verify no further changes in topic branch.
  • [high] 43d5c02c72bdaf59a8e0d4b06f2ae87e42269cbd Fix build on hurd -- is that from a topic branch that can then be annihilated? Verify emails. Verify no further changes in topic branch.
  • 69a17d9d245dc3551792e95e1823cc2d877592f3 Patch [1/4] async-signal safe TLS. -- do we also need an implementation of this? (Not yet called from anywhere?) Now used in 7f507ee17aee720fa423fa38502bc3caa0dd03d7 Async-signal safe TLS. 7f507ee17aee720fa423fa38502bc3caa0dd03d7 has been reverted in 73d61e4f6c65da714c0f8a3a233725322553ceba. 1f33d36a8a9e78c81bed59b47f260723f56bb7e6, 063b2acbce83549df82ab30f5af573f1b9c4bd19, b627fdd58554bc36bd344dc40a8787c4b7a9cc46, e81c64bba13d2d8b2a4e53254a82cc80f27c8497 have been reverted in dd654bf9ba1848bf9ed250f8ebaa5097c383dcf8. 35e8f7ab94c910659de9d507aa0f3e1f8973d914 has been reverted in 8b6785f0836011cace9a77f3c24e51a7379238a0. 69a17d9d245dc3551792e95e1823cc2d877592f3 has been reverted in bf06bcee84d4c19a99925c0f58026a8cbd87a688. a494421f5268df333c589d71104a39bb6a9cff19 has been reverted in f482dbbec775bf72eb6510b6091fca141893c466.
  • [low] In various commits, menual/*.texi files have been annotated regarding MTASC-safety properties. The focus has not necessarily been on Hurd, though.
  • baseline

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 f68531785b6d85fb0b405747688f93471b6a964f (2015-01-23; 9a869d822025be8e43b78234997b10bf0cf9d859 (2014-02-07)) plus 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 reverted, id:"87a9fvguwq.fsf@schwinge.name", SERVERS STARTUP hard-coded to /servers/startup in sysdeps/mach/hurd/reboot.c sources, run on laplace.SCHWINGE.

$ export LC_ALL=C
$ ../Roger_Whittaker/configure --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 600 MiB, and runs for TODO min on kepler.SCHWINGE and 19 min on laplace.SCHWINGE.

Analysis

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

TODO.

• 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 runs for TODO min on kepler.SCHWINGE and 3 min on laplace.SCHWINGE.

Analysis

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

TODO.

Testsuite

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

This runs for TODO min on kepler.SCHWINGE and 10 min on laplace.SCHWINGE.

Specifying fast-check=yes disables the conformtest which ran for 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. elf/tst-xmmymm.out is another candidate to disable: needs 90 min to run.

Analysis

$ toolchain/logs/process glibc test fetch laplace.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/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

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

  libio/tst-atime.out:

  atime has not changed
  

  Due to ext2fs --no-atime.

  • IRC, OFTC, #debian-hurd, 2013-05-08

    <youpi> bah, tst-atime failure :)
    <pinotree> do you have its output?
    <youpi> well it's very simple
    <youpi> I have the noatime option on / :)
    <pinotree> oh
    <youpi> fortunately fsysopts works :)
    <pinotree> the test checks whether ST_NOATIME is in the mount
      options, maybe it would be a good idea to provide it
    <youpi> yes
    <pinotree> unfortunately it isn't in posix, so i'm not sure whether
      adding it to the general bits/statvfs.h would be welcome
    <pinotree> or whether we should fork it, like it is done for linux 
    <pinotree> oh no, we fork it already
    <pinotree> \o/
    

  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, dlfcn/tststatic3.out, dlfcn/tststatic4.out, dlfcn/tststatic5.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

  Intermittent.

  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-sysconf.out

  Fails with:

  sysconf(_SC_BARRIERS) must be 200809L
  sysconf(_SC_READER_WRITER_LOCKS) must be 200809L
  sysconf(_SC_SEMAPHORES) must be 200809L
  sysconf(_SC_SPIN_LOCKS) must be 200809L
  sysconf(_SC_THREAD_ATTR_STACKADDR) must be 200809L
  sysconf(_SC_THREAD_ATTR_STACKSIZE) must be 200809L
  sysconf(_SC_THREADS) must be 200809L
  sysconf(_SC_TIMEOUTS) must be 200809L
  

  That, I presume, is in response to our sysdeps/mach/hurd/bits/posix_opt.h file, which uses 200112L values. nptl/sysdeps/unix/sysv/linux/bits/posix_opt.h uses 200809L values.

• 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)?

• posix/tst-pathconf.out

  pathconf on directory failed: (os/kern) successful
  

• 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.

• 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-shm.out

  read file outside of SHMDIR directory: (os/kern) successful
  

• 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-cpuclock2, 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-auxv.out

  SIGSEGV.

• 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-ptrguard1-static.o, elf/tst-ptrguard1.o

  In file included from tst-ptrguard1-static.c:1:0:
  tst-ptrguard1.c: In function 'con':
  tst-ptrguard1.c:42:24: error: 'tcbhead_t' has no member named 'pointer_guard'
  tst-ptrguard1.c: In function 'do_test':
  tst-ptrguard1.c:65:29: error: 'tcbhead_t' has no member named 'pointer_guard'
  tst-ptrguard1.c:104:30: error: 'tcbhead_t' has no member named 'pointer_guard'
  

  See t/tls.

• elf/tst-tls9-static.out

  SIGSEGV.

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

  SIGKILL.

• elf/tst-null-argv.out

  Inconsistency detected by ld.so: ../sysdeps/mach/hurd/dl-sysdep.c: 338: open_file: Assertion `!(flags & ~(0x0001 | 0x00400000))' failed!
  

• 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.

• debug/tst-longjmp_chk2.out, debug/tst-longjmp_chk3.out, debug/tst-longjmp_chk4.out, debug/tst-longjmp_chk5.out, debug/tst-backtrace2.out, debug/tst-backtrace3.out, debug/tst-backtrace4.out, debug/tst-backtrace5.out debug/tst-backtrace6.out

  All say: Obtained backtrace with 0 functions.

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?

• stdlib/bug-getcontext.out

  getcontext failed, errno: 1073741902.
  

  Fixed, implemented in t/context_functions.

• 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.

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

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