[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20121024211847.GK254@brightrain.aerifal.cx>
Date: Wed, 24 Oct 2012 17:18:47 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Pending issues for release
On Wed, Oct 24, 2012 at 10:06:01PM +0200, John Spencer wrote:
> On 10/24/2012 07:58 PM, Rich Felker wrote:
> >On Wed, Oct 24, 2012 at 05:17:21PM +0200, John Spencer wrote:
> >>On 10/19/2012 04:17 AM, Rich Felker wrote:
> >>>>- explicit mips soft-float abi support (mainly for use with broken
> >>>> openwrt kernels)
> >>>Still need to figure out how best to do this...
> >>i think this one is also not critical for this release, and can be
> >>postponed.
> >I agree it's not _critical_, but since OpenWRT is one of the main
> >MIPS platforms people might be interested in, it's rather frustrating
> >that we can't make working binaries for it. Ultimately somebody
> >building a musl-based OpenWRT or similar would want to rebuild a
> >proper kernel without float ripped out of it (this will definitely
> >give a net space _savings_ when you count the soft-float code getting
> >linked into userspace programs), but if you're just trying to get a
> >few new musl-based binaries onto an existing OpenWRT installation, you
> >may need to play by their rules and use softfloat.
> >
> >Maybe there's some quick partial-workaround we could document in the
> >FAQ or such?
> >
>
> i haven't run into this; maybe simply passing -msoft-float to gcc fixes it ?
No, the problem is that setjmp/longjmp crash (hang, actually, I think)
because the instructions to save/restore floating point registers
don't work. Also, the new fenv functions would crash or hang, but
presumably their use is rare and won't come up in programs being used
on these targets.
To be 100% correct, we need to disable these in soft-float mode, and
also change the fenv header not to advertise the existence of
exceptions or rounding modes. And errno-based math errors need to be
added to all the math functions so math_errhandling can be changed
(this is also needed for ARM's default ABI which lacks floating point
environment).
> >>>>- additional use of vfork (system, popen, wordexp, etc.)
> >>>Mostly done. wordexp remains, and should possibly be reworked to use
> >>>popen or posix_spawn as its backend to avoid code duplication.
> >>what's the current status on this one ?
> >Everything except wordexp is done, but they're not heavily
> >regression-tested. wordexp is rather low priority since nothing
> >serious uses it. Care to check that system, popen, and posix_spawn are
> >working okay in some real use cases?
> i'd prefer having an official tarball (explained below) and testing
> with that;
Testing before release is a lot more valuable than testing after, at
least from a credibility standpoint... :-)
> and since 0.9.7 is an odd version number, it is expected to be buggy
> anyway... ;)
> >>i hope for the release to come out soon, to experiment with the new
> >>TLS support in qemu.
> >What sort of experimentation do you have in mind? Is it anything we
> >could do before a release to help ensure that it's all correctly
> >working?
>
> while building for the mips target, i encountered a serious
> (show-stopper) breakage building perl.
> the in-build perl binary tried to execute code, which apparently was data
> (smells like gcc or dynamic linker breakage), and crashed, unable to
> complete the build.
>
> Program received signal SIGILL, Illegal instruction.
> 0x00593c10 in PL_ppaddr ()
Yes, this could very well be from trying to access TLS variables when
the runtime does not support TLS; it will just read random memory
contents at that location relative to the thread pointer (probably
part of the pthread structure, but could be anything).
> and now to why i want to test with a release instead of a git checkout:
>
> it takes about 2-3 days to get that far with the compilation times
> on qemu mips,
Can't you test on your already-built system, dropping in new musl?
That should take a few hours at most..
> so i'd prefer to use a release for that, in order not to have to
> pull in a huge cumulative
> add-tls patch into sabotage's commit history, and not having to use
> git, which is even worse:
>
> 1) i'd have to have git available in the bootstrap environment,
> which is a pain to build with all its dependencies, and
git can be built with essentially no dependencies.
> 2) network connectivity has to work, which is not the case for
> aboriginal mips image i use,
> 3) to have a reproducible result, i'd had to switch "official"
> sabotage to use git as well (pulling in said dependencies),
> and as soon as a release is out, do everything again to test that
> nothing broke,
> and so we can use a tarball which is the way everything's designed to work.
*nod*, these reasons make sense.
> maybe a better alternative for this scenario is if you would supply
> development snapshot tarballs,
> potentially once a week automatically generated from git head, and
> automatically deleted after 6 months.
> this would free you from the pressure that everything has to be
> perfect for a release, and we integrators
> have something we can use to quickly do updates and regression tests
> without using hacks in our build systems.
Yes, that's a nice idea.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
