* Pending issues for release @ 2012-10-18 18:29 Rich Felker 2012-10-18 22:54 ` Isaac Dunham 2012-10-19 2:17 ` Rich Felker 0 siblings, 2 replies; 8+ messages in thread From: Rich Felker @ 2012-10-18 18:29 UTC (permalink / raw) To: musl Hi all, Once I confirm that there are no stupid bugs blocking threads from working on microblaze (so far I have been unable to test due to buggy qemu), I'd like to make a release. Pending issues I'd like to address before then include: - dl_iterate_phdr patch (npx) - sigreturn(?) and other issues npx wanted for unwinding - integrating the configure patch for better pcc support - inline syscalls for microblaze - explicit mips soft-float abi support (mainly for use with broken openwrt kernels) - make endian.h more robust for opposite-endian builds (mipsel, armeb) And a few other things that might make it in, if I get around to them: - fenv support on mips and microblaze - additional use of vfork (system, popen, wordexp, etc.) - subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.) Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Pending issues for release 2012-10-18 18:29 Pending issues for release Rich Felker @ 2012-10-18 22:54 ` Isaac Dunham 2012-10-18 22:58 ` Rich Felker 2012-10-19 2:17 ` Rich Felker 1 sibling, 1 reply; 8+ messages in thread From: Isaac Dunham @ 2012-10-18 22:54 UTC (permalink / raw) To: musl On Thu, 18 Oct 2012 14:29:57 -0400 Rich Felker <dalias@aerifal.cx> wrote: > Hi all, > Once I confirm that there are no stupid bugs blocking threads from > working on microblaze (so far I have been unable to test due to buggy > qemu), I'd like to make a release. Pending issues I'd like to address > before then include: > > - dl_iterate_phdr patch (npx) > - sigreturn(?) and other issues npx wanted for unwinding > - integrating the configure patch for better pcc support Are there any further comments on that? My main thought is that using +test -z "$LIBCC" && tryldflag LIBCC `$CC -print-file-name=libpcc.a || true` may be unnecessary; if -print-file-name=libpcc.a works, then there shouldn't be a need for more... although pcc does have libpccsoftfloat.a as well. > - inline syscalls for microblaze > - explicit mips soft-float abi support (mainly for use with broken > openwrt kernels) I'm guessing they disabled the FPU emulation for size: on a router, a few kb can change whether you can (for example) add dropbear instead of using Busybox telnetd; I happen to have one where they couldn't. On a related note, would it be possible to add "size of a static busybox binary with a minimal config" (or a static dropbear, or some other program frequently used for embedded systems) to the libc comparison table? I'm thinking that may be the most meaningful metric for people working on embedded systems. > - make endian.h more robust for opposite-endian builds (mipsel, armeb) Don't forget microblazeel (a/k/a microblazele, for the linker) The linker uses -mbig-endian/-mlittle-endian to select, IUIC. > And a few other things that might make it in, if I get around to them: > > - subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.) Perhaps x86-sse eventually? -- Isaac Dunham <idunham@lavabit.com> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Pending issues for release 2012-10-18 22:54 ` Isaac Dunham @ 2012-10-18 22:58 ` Rich Felker 0 siblings, 0 replies; 8+ messages in thread From: Rich Felker @ 2012-10-18 22:58 UTC (permalink / raw) To: musl On Thu, Oct 18, 2012 at 03:54:21PM -0700, Isaac Dunham wrote: > On Thu, 18 Oct 2012 14:29:57 -0400 > Rich Felker <dalias@aerifal.cx> wrote: > > > Hi all, > > Once I confirm that there are no stupid bugs blocking threads from > > working on microblaze (so far I have been unable to test due to buggy > > qemu), I'd like to make a release. Pending issues I'd like to address > > before then include: > > > > - dl_iterate_phdr patch (npx) > > - sigreturn(?) and other issues npx wanted for unwinding > > - integrating the configure patch for better pcc support > > Are there any further comments on that? I don't think the trycc is needed. If pcc is the only compiler installed, c99 or cc should be a symlink/wrapper for it. Trying it _after_ cc/c99 is almost surely not the right thing to do anyway. Normally someone who wants to use pcc will either set CC=pcc manually or have it be their main cc/c99. > My main thought is that using > +test -z "$LIBCC" && tryldflag LIBCC `$CC -print-file-name=libpcc.a || true` > may be unnecessary; if -print-file-name=libpcc.a works, then there shouldn't be a need for more... > although pcc does have libpccsoftfloat.a as well. What does pcc do with -print-file-name=nonexistant.a? gcc does not give an error; it just prints the name without any path. So this would cause gcc to add libpcc.a to the command line if LIBCC is blank... > > - inline syscalls for microblaze > > - explicit mips soft-float abi support (mainly for use with broken > > openwrt kernels) > I'm guessing they disabled the FPU emulation for size: on a router, > a few kb can change whether you can (for example) add dropbear > instead of using Busybox telnetd; I happen to have one where they > couldn't. Yes; I suspect they could have found a way to get the space without breaking the ABI though... > On a related note, would it be possible to add "size of a static > busybox binary with a minimal config" (or a static dropbear, or some > other program frequently used for embedded systems) to the libc > comparison table? I'm thinking that may be the most meaningful > metric for people working on embedded systems. Yes, that's a very good idea. > > - make endian.h more robust for opposite-endian builds (mipsel, armeb) > > Don't forget microblazeel (a/k/a microblazele, for the linker) > The linker uses -mbig-endian/-mlittle-endian to select, IUIC. gcc should handle passing the right options to the linker for the target it's configured for... > > And a few other things that might make it in, if I get around to them: > > > > - subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.) > Perhaps x86-sse eventually? x86-sse is not a different ABI in the sense I'm talking about; the non-sse libc will work fine with apps that use sse, and sse libc will work fine with apps that don't, as long as the cpu supports sse. This is because the calling convention, alignments, etc. are all the same. An example of a different x86 abi would be using pass-by-register (fastcall) for everything (except possibly variadic functions) and passing floating point args/returns in sse registers. This would be a very interesting project, but I'm not sure GCC is up to the task. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Pending issues for release 2012-10-18 18:29 Pending issues for release Rich Felker 2012-10-18 22:54 ` Isaac Dunham @ 2012-10-19 2:17 ` Rich Felker 2012-10-24 15:17 ` John Spencer 1 sibling, 1 reply; 8+ messages in thread From: Rich Felker @ 2012-10-19 2:17 UTC (permalink / raw) To: musl On Thu, Oct 18, 2012 at 02:29:57PM -0400, Rich Felker wrote: > - dl_iterate_phdr patch (npx) > - sigreturn(?) and other issues npx wanted for unwinding Waiting on npx for these. > - integrating the configure patch for better pcc support I will commit the tryldflag changes as-is, but the libpcc search needs improvement. > - inline syscalls for microblaze Done. > - explicit mips soft-float abi support (mainly for use with broken > openwrt kernels) Still need to figure out how best to do this... > - 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. > - subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.) Still unsure how best to do this. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Pending issues for release 2012-10-19 2:17 ` Rich Felker @ 2012-10-24 15:17 ` John Spencer 2012-10-24 17:58 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: John Spencer @ 2012-10-24 15:17 UTC (permalink / raw) To: musl On 10/19/2012 04:17 AM, Rich Felker wrote: > On Thu, Oct 18, 2012 at 02:29:57PM -0400, Rich Felker wrote: >> - dl_iterate_phdr patch (npx) >> - sigreturn(?) and other issues npx wanted for unwinding > Waiting on npx for these. we haven't heard from npx for quite some time; maybe we can skip that for the next release ? >> - integrating the configure patch for better pcc support > I will commit the tryldflag changes as-is, but the libpcc search needs > improvement. > >> - inline syscalls for microblaze > Done. > >> - 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. >> - 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 ? >> - subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.) > Still unsure how best to do this. introducing this right before a release could cause unexpected breakage; imo we should postpone this as well. i hope for the release to come out soon, to experiment with the new TLS support in qemu. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Pending issues for release 2012-10-24 15:17 ` John Spencer @ 2012-10-24 17:58 ` Rich Felker 2012-10-24 20:06 ` John Spencer 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2012-10-24 17:58 UTC (permalink / raw) To: musl On Wed, Oct 24, 2012 at 05:17:21PM +0200, John Spencer wrote: > On 10/19/2012 04:17 AM, Rich Felker wrote: > >On Thu, Oct 18, 2012 at 02:29:57PM -0400, Rich Felker wrote: > >>- dl_iterate_phdr patch (npx) > >>- sigreturn(?) and other issues npx wanted for unwinding > >Waiting on npx for these. > we haven't heard from npx for quite some time; maybe we can skip > that for the next release ? This would be acceptable. > >>- 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? > >>- 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? > >>- subarchs in build system (e.g. mips-softfloat, arm-hardfloat, etc.) > >Still unsure how best to do this. > > introducing this right before a release could cause unexpected > breakage; imo we should postpone this as well. Yeah, I'd rather wait to make major build system changes. > 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? Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Pending issues for release 2012-10-24 17:58 ` Rich Felker @ 2012-10-24 20:06 ` John Spencer 2012-10-24 21:18 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: John Spencer @ 2012-10-24 20:06 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Pending issues for release 2012-10-24 20:06 ` John Spencer @ 2012-10-24 21:18 ` Rich Felker 0 siblings, 0 replies; 8+ messages in thread From: Rich Felker @ 2012-10-24 21:18 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-10-24 21:18 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-10-18 18:29 Pending issues for release Rich Felker 2012-10-18 22:54 ` Isaac Dunham 2012-10-18 22:58 ` Rich Felker 2012-10-19 2:17 ` Rich Felker 2012-10-24 15:17 ` John Spencer 2012-10-24 17:58 ` Rich Felker 2012-10-24 20:06 ` John Spencer 2012-10-24 21:18 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).