[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Oct 2012 22:06:01 +0200
From: John Spencer <maillist-musl@...fooze.de>
To: musl@...ts.openwall.com
Subject: Re: Pending issues for release
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 ?
>>>> - make endian.h more robust for opposite-endian builds (mipsel, armeb)
>>> Done.
>>>
>>>> And a few other things that might make it in, if I get around to them:
>>>>
>>>> - fenv support on mips and microblaze
>>> Done on mips; microblaze does not seem to have working hard-float.
>>>
>>>> - 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;
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 ()
(gdb) disas
Dump of assembler code for function PL_ppaddr:
=> 0x00593c10 <+0>: 0x4b5048
(gdb) disas *0x00593c10
Dump of assembler code for function Perl_pp_null:
0x004b5048 <+0>: lui gp,0x5a
0x004b504c <+4>: addiu gp,gp,-12224
...
=> 0x00593c10 <+0>: 0x4b5048 ?
perl-5.16.0/op.c: first->op_ppaddr = PL_ppaddr[OP_QR];
since --disable-tls doesn't work on MIPS (not implemented in GCC 3.4.6),
i had to specifically
patch elfutils to use a static variable instead of a TLS one.
i hope that having real TLS and getting rid of that possibly buggy
workaround
(which could affect gcc, the only libelf-consumer) fixes this issue.
it's also possible that it is a bug in the dynlinker that has been fixed
since 0.9.6.
additionally i updated stage1 gcc from 4.5.3 to 4.5.4 since.
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,
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
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.
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.
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.
