diff options
Diffstat (limited to 'open_issues/glibc.mdwn')
| -rw-r--r-- | open_issues/glibc.mdwn | 723 |
1 files changed, 712 insertions, 11 deletions
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index a9c12e5c..26e04768 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -83,6 +83,35 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 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 @@ -192,8 +221,13 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several `MAP_*`|glibc/mmap]] + Check also the content of `gnu/stubs.h`, which lists all the functions + marked as stub which only return `ENOSYS`. + * `chflags` + Patch sent, [[!message-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 @@ -270,11 +304,7 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 initialization <tschwinge> OK, that at least matches my understanding. - * `syncfs` - - We should be easily able to implement that one. - - * `futimesat`, `readlinkat` + * `futimesat` If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`. @@ -337,6 +367,24 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 <pinotree> like posix/tst-waitid.c, you mean? <youpi> yes + * `getconf` things + + IRC, freenode, #hurd, 2012-10-03 + + <pinotree> getconf -a | grep CACHE + <Tekk_> pinotree: I hate spoiling data, but 0 :P + <pinotree> had that feeling, but wanted to be sure -- thanks! + <Tekk_> http://dpaste.com/809519/ + <Tekk_> except for uhh + <Tekk_> L4 linesize + <Tekk_> that didn't have any number associated + <pinotree> weird + <Tekk_> I actually didn't even know that there was L4 cache + <pinotree> what do you get if you run `getconf + LEVEL4_CACHE_LINESIZE`? + <Tekk_> pinotree: undefined + <pinotree> expected, given the output above + For specific packages: * [[octave]] @@ -348,6 +396,9 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 * 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`: @@ -371,6 +422,270 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 * `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 + + [[!message-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 + + [[!message-id "201211172058.21035.toscano.pino@tiscali.it"]]. + + * `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 + + * `LD_DEBUG` + + IRC, freenode, #hurd, 2012-11-22 + + <pinotree> woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and + then sigsegv + <tschwinge> Yeah, that's known for years... :-D + <tschwinge> Probably not too difficult to resolve, though. + * Verify baseline changes, if we need any follow-up changes: * a11ec63713ea3903c482dc907a108be404191a02 @@ -504,9 +819,9 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 kinds of unused configuration options and dead code.`). `NO_STARTER` changes (should be OK). * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify - malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237, `BZ - 11929`. Is this all kosher for us? See [[!message-id - "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. + malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237, + [[!sourceware_PR 11929]]. Is this all kosher for us? See + [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls option, TLS support is required`). * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in @@ -556,6 +871,11 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 using that one (with `sysdeps/mach/nanosleep.c`) instead of `sysdeps/mach/sleep.c`? * *baseline* + * ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd, + 2012-11-20, pinotree: »tschwinge: i agree on your comments on + ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's + sleep.c is buggy (not considers interruption, extra time() (= RPC) + call)«. ## Update @@ -604,7 +924,7 @@ default]` identifiers which warning flag triggered. TODO. - * With GCC 4.5, there's a ton of these warnings: + * With GCC >= 4.5, there's a ton of these warnings: hurd/hurd.h: In function '__hurd_fail': hurd/hurd.h:73: warning: case value '0' not in enumerated type 'error_t' @@ -749,8 +1069,378 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]: There is quite a baseline of failures. + * `annexc.out` + + TODO + + * `bug22.out` + + TODO + + * `bug-atexit3.out` + + TODO + + * `bug-getcontext.out` + + getcontext failed, errno: 1073741902. + + Is not implemented; see above. In 8958805c11c741d9211e20612c86271d906c9a0b + testing, `stdlib/bug-getcontext.out` now says: *Skipping test; no support + for FP exceptions.*, in cba1c83ad62a11347684a9daf349e659237a1741 testing, + it's back to the previous failure. + + * `bug-regex31-mem`, `tst-error1-mem`, `tst-fnmatch-mem`, + `tst-fopenloc.check` + + *output* files: some memory not freed. + + Caused by different memory allocation way in libio, see also + [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]] + + * `bug-ulimit1.out` + + Buggy sysdeps/unix/bsd/ulimit.c return values. + + [[!message-id "201211182342.51619.toscano.pino@tiscali.it"]] + + * `check-execstack.out` + + $BUILDDIR/libc.so.phdr: *** executable stack signaled + + * `check-local-headers.out` + + Most of the external headers used are: + + * `/usr/include/device/bpf.h` + + * `/usr/include/device/device_types.h` + + * `/usr/include/device/net_status.h` + + * `/usr/include/cthreads.h` + + * `/usr/include/hurd/hurd_types.h` + + * `/usr/include/hurd/ioctls.defs` + + * `/usr/include/hurd/ioctl_types.h` + + * `/usr/include/hurd/paths.h` + + * `check-localplt.out` + + Around 500 or so `Extra PLT reference`. + + * `check-textrel.out` + + $BUILDDIR/libc.so.dyn: *** text relocations used + + * `opendir-tst1.out`, `tst-fdopendir2.out` + + `opendir` and `fdopendir` do not return `ENOTDIR` if `fd` is not a directory. + + * `test-assert-perr.out` + + TODO + + * `math/test-idouble`, `math/test-ifloat`, `math/test-ildoubl`, + `math/test-ldouble` + + SIGSEGV. + + * `test-float.out` + + TODO + + * `test-lfs.out` + + TODO + + * `test-multiarch.out` + + Needs [[`/proc/cpuinfo`|hurd/translator/procfs/jkoenig/discussion]] + providing the `flags` line. + + * `tst-aio2`, `tst-aio3`, + `tst-mqueue3`, `tst-mqueue6`, + `tst-mqueue8`, `tst-thrlock`, `tst-timer3`, + `libnss_test1.so` + + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + * `tst-aio8.out`, `tst-aio9.out`, `tst-aio10` -### Additional Failures Compared to Debian + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + Most will compile and work (except `tst-aio`, `tst-aio9`, `tst-aio10`) with + [[!message-id "201209302353.51055.toscano.pino@tiscali.it"]] in libpthread. + + * `tst-array*` + + Failures also seen on GNU/Linux; [[!message-id + "50950082.1070906@df1tl.local.here"]]. + + gcc-4.6 tst-array1.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/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out] Error 1 + gcc-4.6 tst-array2.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/ + gcc-4.6 tst-array2dep.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -fPIC -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc + gcc-4.6 -shared -static-libgcc -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,defs -B[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/ -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -L[...]/tschwinge/Roger_Whittaker.build-gcc-4.6 + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out tst-array2.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out] Error 1 + gcc-4.6 tst-array3.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/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out] Error 1 + gcc-4.6 tst-array4.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/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out tst-array4.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out] Error 1 + + `tst-array5` passes. + + gcc-4.6 tst-array1-static.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 + gcc-4.6 -nostdlib -nostartfiles -static -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crt0.o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crti + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static > [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out] Error 1 + + `tst-array5-static` passes. + + * `tst-audit1.out`, `tst-audit2.out` + + SIGKILL. + + * `tst-chk1.out` + + TODO + + * `tst-chk2.out` + + TODO + + * `tst-chk3.out` + + TODO + + * `tst-chk4.out` + + TODO + + * `tst-chk5.out` + + TODO + + * `tst-chk6.out` + + TODO + + * `tst-cputimer1.o`, `tst-cputimer2.o`, `tst-cputimer3.o`, + `tst-timer4.o`, `tst-timer5.o` + + Missing `SIGRTMIN`. + + All these tests #include `tst-timer4.c`. + + * `tst-timer5.o` + + TODO + + * `tst-dlmopen1.out` + + TODO + + * `tst-ether_line.o` + + tst-ether_line.c: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_PR 11142]]. + + * `tst-fdopendir.out` + + directory atime changed + + TODO + + * `tst-futimesat.out` + + `futimesat` is a stub. + + * `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` will be cleanly solved with + [[!message-id "201209302353.51055.toscano.pino@tiscali.it"]] and libpthread + compiled as add-on. + + * `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. + + * `tst-lfschk2.out` + + TODO + + * `tst-lfschk3.out` + + TODO + + * `tst-lfschk4.out` + + TODO + + * `tst-lfschk5.out` + + TODO + + * `tst-lfschk6.out` + + TODO + + * `tst-longjmp_chk2.out` + + TODO + + * `tst-mqueue5.o` + + Missing `SIGRTMIN`. + + * `tst-pselect.o` + + Missing `SA_NOCLDWAIT`. + + * `tst-secure-getenv.out` + + Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]]. + + * `tst-sprofil.out` + + Floating point exception + + * `tst-stackguard1.out` + + TODO + + * `tst-stackguard1-static.out` + + TODO + + * `tststatic2.out` + + TODO + + * `tststatic.out` + + TODO + + * `tst-strtod-round.out` + + TODO + + * `tst-timer2.o` + + Missing `SIGRTMIN`. + + * `tst-timer.out` + + TODO + + * `tst-tls9-static.out` + + TODO + + * `tst-unique3lib.so`, `tst-unique3lib2.so`, `tst-unique4lib.so` + + Only with GCC 4.4; no longer with 4.5 or 4.6: + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/elf/tst-unique3lib.os:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0' + + * `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 + + TODO + + * `tst-waitid.out` + + Fails sometimes (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`). + + +### Additional Failures Compared to Debian (OLD) $ 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 @@ -789,6 +1479,14 @@ There is quite a baseline of failures. * `posix/tst-getconf` + 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` will be cleanly solved with + [[!message-id "201209302353.51055.toscano.pino@tiscali.it"]] and libpthread + compiled as add-on. + Ends with: getconf POSIX_ALLOC_SIZE_MIN /: /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/posix/getconf: pathconf: /: Invalid argument @@ -838,10 +1536,13 @@ There is quite a baseline of failures. Floating point exception - * `posix/bug-regex31-mem`, `posix/tst-fnmatch-mem` + * `posix/bug-regex31-mem`, `posix/tst-fnmatch-mem`, `misc/tst-error1-mem`, + `libio/tst-fopenloc.check` *output* files: some memory not freed. + [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]] + * `assert/test-assert.out` Fails sometimes... |