Re: Pending issues for release

[Rich Felker <dalias@aerifal.cx>]

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