diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/glibc.mdwn | 68 | ||||
| -rw-r--r-- | open_issues/glibc/t/tls.mdwn | 2 | ||||
| -rw-r--r-- | open_issues/versioning.mdwn (renamed from open_issues/glibc/0.4.mdwn) | 47 |
3 files changed, 109 insertions, 8 deletions
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 8d18d1e2..e72b59d3 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -18,6 +18,8 @@ Here's what's to be done for maintaining glibc. # [[General information|/glibc]] + * [[Versioning]] + # [[Sources|source_repositories/glibc]] @@ -2404,6 +2406,70 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 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: http://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> @@ -2699,7 +2765,7 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 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_PR 15605]]. For + optimization` -- have to revert, see [[!sourceware_PR 15605]]. For analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49. * 6c82a2f8d7c8e21e39237225c819f182ae438db3 `Coordinate IPv6 definitions for Linux and glibc` -- alright for us? diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn index eba2b88b..b10703fd 100644 --- a/open_issues/glibc/t/tls.mdwn +++ b/open_issues/glibc/t/tls.mdwn @@ -71,7 +71,7 @@ After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's <youpi> have you had a look at the tls.pdf from Uli ? <youpi> all the gory details are there :) -Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[sourceware_PR 15754]], adds +Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[!sourceware_PR 15754]], adds `sysdeps/i386/stackguard-macros.h:POINTER_CHK_GUARD`, which is not correct for us (at the moment), but it also shouldn't cause any harm, as this file is only used in `elf/tst-ptrguard1.c` and `elf/tst-stackguard1.c`, which now will fail diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/versioning.mdwn index 33ef8f3a..1987b6ca 100644 --- a/open_issues/glibc/0.4.mdwn +++ b/open_issues/versioning.mdwn @@ -9,17 +9,52 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_glibc open_issue_libpthread]] +Things to consider regarding *versioning*. + +The provider and user of any interface need to agree about how to interpret the +data being exchanged. Internal-only interfaces can be changed easily, because +you can change the provider and user at the same time. Interfaces that are +exposed externally require more attention, for obvious reasons. To *change* +interfaces means to either remove, or add, or modify an existing interface. +Modify basically means to remove and then re-add a variant, re-using the former +name/identifier. + +[[!toc]] + + +# [[RPC]]s + +## [[microkernel/mach/message/msgh_id]] + + +# Shared Libraries -Things to consider doing when bumping the glibc SONAME. + * [[!wikipedia soname]] + * ELF symbol versioning + * [[!wikipedia "GNU Libtool"]] + + +## Hurd + +Transition to "normal" ELF symbol versioning/libtool? + +For all libraries, the SONAME is currently set to *0.3*. [[!message-id +desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the +[[Hurd 0.5 release|news/2013-09-27]]. + + +## glibc + +Bump the glibc SONAME to some point, or can do everything with symbol +versioning? There are some comments in the sources, for example `hurd/geteuids.c`: `XXX Remove this alias when we bump the libc soname.` -[[!toc]] +### IRC, freenode, #hurd, 2012-12-14 -# IRC, freenode, #hurd, 2012-12-14 +[[!tag open_issue_glibc open_issue_libpthread]] In context of [[packaging_libpthread]]/[[libpthread]]. @@ -38,9 +73,9 @@ In context of [[packaging_libpthread]]/[[libpthread]]. "4BFA500A.7030502@gmail.com"]]. -# `time_t` -- Unix Epoch vs. 2038 +### `time_t` -- Unix Epoch vs. 2038 -## IRC, freenode, #hurd, 2013-12-12 +#### IRC, freenode, #hurd, 2013-12-12 <azeem> because it gets discussed in #debian-devel for the Linux i386 architecture right now: what's the deal with hurd-i386 and the 32bit |