Pending issues for release

Pending issues for release

[Rich Felker]

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

Re: Pending issues for release

[Isaac Dunham]

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>

Re: Pending issues for release

[Rich Felker]

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

Re: Pending issues for release

[Rich Felker]

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

Re: Pending issues for release

[John Spencer]

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.

Re: Pending issues for release

[Rich Felker]

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

Re: Pending issues for release

[John Spencer]

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.

Re: Pending issues for release

[Rich Felker]

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