musl 0.9.8 released

musl 0.9.8 released

[Rich Felker]

Release announcement for musl 0.9.8:

    New PowerPC port and major bug fixes and improvements for the MIPS
    port. Coverage for more optional parts of POSIX including the
    thread priority scheduling option and stubs for unsupported
    functionality. Dynamic linker dl_iterate_phdr support. Various
    minor bugs and strict conformance issues have also been fixed and
    application compatibility improved.

    http://www.musl-libc.org/releases/musl-0.9.8.tar.gz

As a post-release agenda, I'd like to first address things that have
been in demand lately:

- Proper MIPS softfloat support
- x32 port
- ether.h interfaces
- %m modifier for scanf
- Affinity/cpuset stuff

And I have a few agenda items of my own:

- Self-synchronized destruction of FILE streams (same issue all
  synchronization objects have had with self-synchronized
  destruction -- unlocking thread may not access memory after the
  destroying thread already got the lock).
- Making stdio functions cancellable while waiting for locks.
- Getting strace & gdb working properly with minimal patching.

That's about it..hopefully the next release cycle won't take so long.

Rich

Re: musl 0.9.8 released

[Szabolcs Nagy]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

* Rich Felker <dalias@aerifal.cx> [2012-11-26 21:49:58 -0500]:
> As a post-release agenda, I'd like to first address things that have
> been in demand lately:
> 
> - Proper MIPS softfloat support
> - x32 port
> - ether.h interfaces
> - %m modifier for scanf
> - Affinity/cpuset stuff
> 
> And I have a few agenda items of my own:
> 
> - Self-synchronized destruction of FILE streams (same issue all
>   synchronization objects have had with self-synchronized
>   destruction -- unlocking thread may not access memory after the
>   destroying thread already got the lock).
> - Making stdio functions cancellable while waiting for locks.
> - Getting strace & gdb working properly with minimal patching.
> 

+ more math fixes :)

i found minor restrict qualifier issues in some of the new
interfaces

[-- Attachment #2: restrict.diff --]
[-- Type: text/x-diff, Size: 1691 bytes --]

diff --git a/include/spawn.h b/include/spawn.h
index 92b77f7..29c799e 100644
--- a/include/spawn.h
+++ b/include/spawn.h
@@ -57,8 +57,8 @@ int posix_spawnattr_getsigdefault(const posix_spawnattr_t *__restrict, sigset_t
 
 int posix_spawnattr_setschedparam(posix_spawnattr_t *__restrict, const struct sched_param *__restrict);
 int posix_spawnattr_getschedparam(const posix_spawnattr_t *__restrict, struct sched_param *__restrict);
-int posix_spawnattr_setschedpolicy(posix_spawnattr_t *__restrict, int);
-int posix_spawnattr_getschedpolicy(const posix_spawnattr_t *__restrict, int *);
+int posix_spawnattr_setschedpolicy(posix_spawnattr_t *, int);
+int posix_spawnattr_getschedpolicy(const posix_spawnattr_t *__restrict, int *__restrict);
 
 int posix_spawn_file_actions_init(posix_spawn_file_actions_t *);
 int posix_spawn_file_actions_destroy(posix_spawn_file_actions_t *);
diff --git a/src/thread/pthread_attr_get.c b/src/thread/pthread_attr_get.c
index e4650e4..ad913c5 100644
--- a/src/thread/pthread_attr_get.c
+++ b/src/thread/pthread_attr_get.c
@@ -11,7 +11,7 @@ int pthread_attr_getguardsize(const pthread_attr_t *restrict a, size_t *restrict
 	return 0;
 }
 
-int pthread_attr_getinheritsched(const pthread_attr_t *a, int *inherit)
+int pthread_attr_getinheritsched(const pthread_attr_t *restrict a, int *restrict inherit)
 {
 	*inherit = a->_a_sched;
 	return 0;
@@ -23,7 +23,7 @@ int pthread_attr_getschedparam(const pthread_attr_t *restrict a, struct sched_pa
 	return 0;
 }
 
-int pthread_attr_getschedpolicy(const pthread_attr_t *a, int *policy)
+int pthread_attr_getschedpolicy(const pthread_attr_t *restrict a, int *restrict policy)
 {
 	*policy = a->_a_policy;
 	return 0;

Re: musl 0.9.8 released

[Rich Felker]

On Tue, Nov 27, 2012 at 12:31:02PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2012-11-26 21:49:58 -0500]:
> > As a post-release agenda, I'd like to first address things that have
> > been in demand lately:
> > 
> > - Proper MIPS softfloat support
> > - x32 port
> > - ether.h interfaces
> > - %m modifier for scanf
> > - Affinity/cpuset stuff
> > 
> > And I have a few agenda items of my own:
> > 
> > - Self-synchronized destruction of FILE streams (same issue all
> >   synchronization objects have had with self-synchronized
> >   destruction -- unlocking thread may not access memory after the
> >   destroying thread already got the lock).
> > - Making stdio functions cancellable while waiting for locks.
> > - Getting strace & gdb working properly with minimal patching.
> > 
> 
> + more math fixes :)

:)

> i found minor restrict qualifier issues in some of the new
> interfaces

Committed.

Rich

Re: musl 0.9.8 released

[Isaac Dunham]

On Mon, 26 Nov 2012 21:49:58 -0500
Rich Felker <dalias@aerifal.cx> wrote:

> 
> Release announcement for musl 0.9.8:
> 
>     New PowerPC port and major bug fixes and improvements for the MIPS
>     port. Coverage for more optional parts of POSIX including the
>     thread priority scheduling option and stubs for unsupported
>     functionality. Dynamic linker dl_iterate_phdr support. Various
>     minor bugs and strict conformance issues have also been fixed and
>     application compatibility improved.
Thanks!
> 
>     http://www.musl-libc.org/releases/musl-0.9.8.tar.gz

Mirrored at github.com/idunham/musl branch "master"

> As a post-release agenda, I'd like to first address things that have
> been in demand lately:
> 
> - Proper MIPS softfloat support
> - x32 port
> - ether.h interfaces
> - %m modifier for scanf
> - Affinity/cpuset stuff
> 
> And I have a few agenda items of my own:
> 
> - Self-synchronized destruction of FILE streams (same issue all
>   synchronization objects have had with self-synchronized
>   destruction -- unlocking thread may not access memory after the
>   destroying thread already got the lock).
> - Making stdio functions cancellable while waiting for locks.
> - Getting strace & gdb working properly with minimal patching.
> 
> That's about it..hopefully the next release cycle won't take so long.
> 
> Rich

All very good, and I don't think I've got any more to add...

So I guess that leaves the subarches like so:
x86:  i486, x86_64
arm:  arm(eb), armel
mips: mips(32), mipsel(32)
microblaze: microblaze
(What's the status of microblazeel/microblazele? configure looks not to recognize it...)
ppc:  powerpc(32)

Total arches:
6
Total subarches (distinct ABIs):
8-10 (depending on status of microblazeel and ABI compatability of armhf with armel)

-planned subarches: mipsel32-sf, mips32-sf
-planned arches: x32
-distant: mips64, mipsel64, ppc64 (I *think* Rich Pennington got these working, but they haven't been merged)
-unsupported subarches: i386

It seems Debian's using aarch64-* for ARMv8.

-- 
Isaac Dunham <idunham@lavabit.com>

Re: musl 0.9.8 released

[Rich Felker]

On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote:
> All very good, and I don't think I've got any more to add...
> 
> So I guess that leaves the subarches like so:
> x86:  i486, x86_64

i386 and x86_64 aren't subarchs of a common arch. They're completely
independent ISAs and cannot share any code.

> arm:  arm(eb), armel
> mips: mips(32), mipsel(32)
> microblaze: microblaze
> (What's the status of microblazeel/microblazele? configure looks not
> to recognize it...)

It should work aside from configure not recognizing it. But I don't
think it's been tested.

> ppc:  powerpc(32)
> 
> Total arches:
> 6
> Total subarches (distinct ABIs):
> 8-10 (depending on status of microblazeel and ABI compatability of
> armhf with armel)
> 
> -planned subarches: mipsel32-sf, mips32-sf

My idea for the names would be something like: mips, mipsel, mips-sf,
mipsel-sf, ...

Basically, the full arch name would be something along the lines of:

arch[el|eb][-abivariant]

which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where
only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for
asm files. But additional considerations need to be made for how the
main arch dir with bits headers and internal headers would be
selected. I don't think we want to duplicate entire arch trees for
subarchs, but I also don't see how subarchs can get by with using the
same set of headers unless we rely on the compiler to predefine macros
that distinguish them. This is rather ugly but we're already partially
relying on it for endianness varants.

In the end, it might simply be the cleanest to just duplicate the
trees, but use symlinks to eliminate most of the duplicate files.
However, the interaction of that with install rules would have to be
considered and the install rules might need revision.

> -planned arches: x32

Yes. I think x32 (and mipsn32) probably need to be considered as
separate archs, despite being the same ISAs as x86_64 (and mips64).

> -distant: mips64, mipsel64, ppc64 (I *think* Rich Pennington got
> these working, but they haven't been merged)

Well, for a very limited definition of working. A majority of the
actual *code* is done, but the headers were basically all just copies
of the arm headers, meaning not much actually works.

> -unsupported subarches: i386

??

> It seems Debian's using aarch64-* for ARMv8.

Yes, 64-bit arm is a new arch and it seems they used the name aarch64
instead of arm64 due to arm* being interpreted as 32-bit arm by many
things..

Rich

Re: musl 0.9.8 released

[Isaac Dunham]

On Tue, 27 Nov 2012 22:39:48 -0500
Rich Felker <dalias@aerifal.cx> wrote:

> On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote:

> > arm:  arm(eb), armel
> > mips: mips(32), mipsel(32)
> > microblaze: microblaze
> > (What's the status of microblazeel/microblazele? configure looks not
> > to recognize it...)
> 
> It should work aside from configure not recognizing it. But I don't
> think it's been tested.
> 
> > ppc:  powerpc(32)
> > 
> > Total arches:
> > 6
> > Total subarches (distinct ABIs):
> > 8-10 (depending on status of microblazeel and ABI compatability of
> > armhf with armel)
> > 
> > -planned subarches: mipsel32-sf, mips32-sf
> 
> My idea for the names would be something like: mips, mipsel, mips-sf,
> mipsel-sf, ...
 
> Basically, the full arch name would be something along the lines of:
> 
> arch[el|eb][-abivariant]
> 
> which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where
> only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for
> asm files. But additional considerations need to be made for how the
> main arch dir with bits headers and internal headers would be
> selected. I don't think we want to duplicate entire arch trees for
> subarchs, but I also don't see how subarchs can get by with using the
> same set of headers unless we rely on the compiler to predefine macros
> that distinguish them. This is rather ugly but we're already partially
> relying on it for endianness varants.

Where would the headers need to differ by subarch?
I'm guessing this is mainly stuff like fenv?

> In the end, it might simply be the cleanest to just duplicate the
> trees, but use symlinks to eliminate most of the duplicate files.
> However, the interaction of that with install rules would have to be
> considered and the install rules might need revision.

<snip>

> > -unsupported subarches: i386
> 
> ??
The 80386 processor, as opposed to 80486.

# On x86, make sure we don't have incompatible instruction set
# extensions enabled by default. This is bad for making static binaries.
# We cheat and use i486 rather than i386 because i386 really does not
# work anyway (issues with atomic ops).

Also, I can't seem to find it now, but somewhere I heard that upstream gcc and/or glibc with the "i386-linux-*" triplet has some incompatability with "i486-linux-*".  IIRC, I heard that some distros patch this to treat i386-linux-* as if it meant i486.
But, I can't trace the source for that claim, so don't count on it...

> > It seems Debian's using aarch64-* for ARMv8.
> 
> Yes, 64-bit arm is a new arch and it seems they used the name aarch64
> instead of arm64 due to arm* being interpreted as 32-bit arm by many
> things..
> 
ie, due to the insane number of ABIs and triplets that ARM has?
arm (bigendian/OABI), armeabi (bigendian: armeb), armel (littleendian variant of EABI), armhf (armel + vfp3)

-- 
Isaac Dunham <idunham@lavabit.com>

Re: musl 0.9.8 released

[Rich Felker]

On Tue, Nov 27, 2012 at 08:51:16PM -0800, Isaac Dunham wrote:
> > > -planned subarches: mipsel32-sf, mips32-sf
> > 
> > My idea for the names would be something like: mips, mipsel, mips-sf,
> > mipsel-sf, ...
>  
> > Basically, the full arch name would be something along the lines of:
> > 
> > arch[el|eb][-abivariant]
> > 
> > which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where
> > only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for
> > asm files. But additional considerations need to be made for how the
> > main arch dir with bits headers and internal headers would be
> > selected. I don't think we want to duplicate entire arch trees for
> > subarchs, but I also don't see how subarchs can get by with using the
> > same set of headers unless we rely on the compiler to predefine macros
> > that distinguish them. This is rather ugly but we're already partially
> > relying on it for endianness varants.
> 
> Where would the headers need to differ by subarch?
> I'm guessing this is mainly stuff like fenv?

Yes, probably the floating-point headers are the main places: fenv.h,
float.h, and math.h.

> > > -unsupported subarches: i386
> > 
> > ??
> The 80386 processor, as opposed to 80486.
> 
> # On x86, make sure we don't have incompatible instruction set
> # extensions enabled by default. This is bad for making static binaries.
> # We cheat and use i486 rather than i386 because i386 really does not
> # work anyway (issues with atomic ops).

This is fairly comparable to the mips1 issue and the need for ll/sc
emulation by the kernel. i386 is just fundamentally lacking in a way
that makes multi-tasking/multi-threading not workable with the POSIX
apis for it. The kernel should be emulating 'lock cmpxchg', like it
does ll/sc for mips1, and if it did, 386 would work fine. But
apparently nobody cares anyway..

> Also, I can't seem to find it now, but somewhere I heard that
> upstream gcc and/or glibc with the "i386-linux-*" triplet has some
> incompatability with "i486-linux-*". IIRC, I heard that some distros
> patch this to treat i386-linux-* as if it meant i486.
> But, I can't trace the source for that claim, so don't count on it...

This doesn't make any sense to me.

> > > It seems Debian's using aarch64-* for ARMv8.
> > 
> > Yes, 64-bit arm is a new arch and it seems they used the name aarch64
> > instead of arm64 due to arm* being interpreted as 32-bit arm by many
> > things..
> > 
> ie, due to the insane number of ABIs and triplets that ARM has?
> arm (bigendian/OABI), armeabi (bigendian: armeb), armel
> (littleendian variant of EABI), armhf (armel + vfp3)

:-)

Rich

Re: musl 0.9.8 released

[Rob Landley]

On 11/28/2012 07:05:07 AM, Rich Felker wrote:
> This is fairly comparable to the mips1 issue and the need for ll/sc
> emulation by the kernel. i386 is just fundamentally lacking in a way
> that makes multi-tasking/multi-threading not workable with the POSIX
> apis for it. The kernel should be emulating 'lock cmpxchg', like it
> does ll/sc for mips1, and if it did, 386 would work fine. But
> apparently nobody cares anyway..

Actually this just got removed literally today:

   https://lkml.org/lkml/2012/11/28/445

If I recall, there was a longish discussion that boiled down to nobody  
could find actual 386 hardware still in use to test any of this with.

Technically intel still made them until 5 years ago, but for aerospace  
and such rather than use in general purpose computers:

http://www.reghardware.com/2006/05/18/intel_cans_386_486_960_cpus/

Rob

Re: musl 0.9.8 released

[Rich Felker]

On Wed, Nov 28, 2012 at 03:35:56PM -0600, Rob Landley wrote:
> On 11/28/2012 07:05:07 AM, Rich Felker wrote:
> >This is fairly comparable to the mips1 issue and the need for ll/sc
> >emulation by the kernel. i386 is just fundamentally lacking in a way
> >that makes multi-tasking/multi-threading not workable with the POSIX
> >apis for it. The kernel should be emulating 'lock cmpxchg', like it
> >does ll/sc for mips1, and if it did, 386 would work fine. But
> >apparently nobody cares anyway..
> 
> Actually this just got removed literally today:
> 
>   https://lkml.org/lkml/2012/11/28/445

*sigh* that's frustrating.

> If I recall, there was a longish discussion that boiled down to
> nobody could find actual 386 hardware still in use to test any of
> this with.

It would be easy to test on qemu. I even have a 386 board I could set
back up and test...

Rich

Re: musl 0.9.8 released

[Rob Landley]

On 11/28/2012 05:53:04 PM, Rich Felker wrote:
> On Wed, Nov 28, 2012 at 03:35:56PM -0600, Rob Landley wrote:
> > On 11/28/2012 07:05:07 AM, Rich Felker wrote:
> > >This is fairly comparable to the mips1 issue and the need for ll/sc
> > >emulation by the kernel. i386 is just fundamentally lacking in a  
> way
> > >that makes multi-tasking/multi-threading not workable with the  
> POSIX
> > >apis for it. The kernel should be emulating 'lock cmpxchg', like it
> > >does ll/sc for mips1, and if it did, 386 would work fine. But
> > >apparently nobody cares anyway..
> >
> > Actually this just got removed literally today:
> >
> >   https://lkml.org/lkml/2012/11/28/445
> 
> *sigh* that's frustrating.

Turns out I was wrong, the patch series hasn't been merged yet, it's  
just an RFC. (I only skim linux-kernel these days, too much traffic.)  
If you wanted to speak against it, the thread starts here:

http://lkml.indiana.edu/hypermail/linux/kernel/1211.3/02304.html

Rob

Re: musl 0.9.8 released

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-11-26 21:49:58 -0500]:
> As a post-release agenda, I'd like to first address things that have
> been in demand lately:
> 
> - Proper MIPS softfloat support
> - x32 port
> - ether.h interfaces
> - %m modifier for scanf
> - Affinity/cpuset stuff
> 
> And I have a few agenda items of my own:
> 
> - Self-synchronized destruction of FILE streams (same issue all
>   synchronization objects have had with self-synchronized
>   destruction -- unlocking thread may not access memory after the
>   destroying thread already got the lock).
> - Making stdio functions cancellable while waiting for locks.
> - Getting strace & gdb working properly with minimal patching.
> 

i just remembered that there was a request about tzdata support
with proper zoneinfo parsing instead of just posix TZ

Re: musl 0.9.8 released

[Rich Felker]

On Mon, Dec 03, 2012 at 02:11:17PM +0100, Szabolcs Nagy wrote:
> i just remembered that there was a request about tzdata support
> with proper zoneinfo parsing instead of just posix TZ

Yes. I'd forgotten about that. It doesn't necessarily need to be on
the agenda for the next release cycle, but it definitely needs to be
in the 1.0 wishlist. I think I'll post a revised 1.0 wishlist with
possible time frames for each item..

As for zoneinfo support, what it basically amounts to is writing a
single function that, given a time in seconds since the epoch, runs
over the mmapped zoneinfo binary format file and returns the timezone
offset at that moment. It might also need the ability to determine
separately the DST and non-DST offsets for the year that time falls in
(for use with mktime) -- this could be done via an extra argument to
the function, like the tm_isdst field, with 3 possible values -- and
the ability to get the DST and non-DST names of the timezone.

Would you or anyone else be interested in taking a shot at writing
such a function? I remember I looked at it a while back and it didn't
seem so hard, but the zoneinfo file format was really ugly with a lot
of unnecessary indirection.

Rich

Re: musl 0.9.8 released

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-12-03 12:30:19 -0500]:
> in the 1.0 wishlist. I think I'll post a revised 1.0 wishlist with
> possible time frames for each item..

that will be useful

> As for zoneinfo support, what it basically amounts to is writing a
> single function that, given a time in seconds since the epoch, runs
..
> Would you or anyone else be interested in taking a shot at writing
> such a function? I remember I looked at it a while back and it didn't
> seem so hard, but the zoneinfo file format was really ugly with a lot
> of unnecessary indirection.

i have other things queued now
but can look into it later