Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20220509174921.GE7074@brightrain.aerifal.cx>
Date: Mon, 9 May 2022 13:49:22 -0400
From: Rich Felker <dalias@...c.org>
To: Rob Landley <rob@...dley.net>
Cc: musl@...ts.openwall.com
Subject: Re: Coldfire toolchain.

On Mon, May 09, 2022 at 06:51:57AM -0500, Rob Landley wrote:
> So I lightly hacked my mcm-buildall.sh wrapper script to do:
> 
> ../mcm-buildall.sh m68k:linux-uclinux:"--with-arch=cf --with-cpu=5208
> --enable-default-pie"
> 
> And with an m68k-linux-uclinux tuple (because it's looking for -linux and -musl
> both with a dash in front of them, and thus can't accept one with both), the
> compiler builds but then musl's build fails with:

*-uclinux isn't a valid tuple for musl target. If you're using a
nondefault ABI, you can reflect that in the tuple name as a vendor
label (the optional 4th component) or preferably a suffix (with no -)
after musl, e.g. muslcf. Here there may also be a way you can encode
the difference in the cpu type name; I'm not sure. But if your tuple
isn't *-musl* then gcc will wrongly have glibc or uclibc assumptions.

> checking whether compiler's long double definition matches float.h... no
> .../src_musl/configure: error: unsupported long double type
> 
> And grepping the compiler's #defines for DOUBLE gives:
> 
> #define __DBL_DENORM_MIN__ ((double)4.9406564584124654e-324L)
> #define __SIZEOF_LONG_DOUBLE__ 8
> #define __DBL_MAX__ ((double)1.7976931348623157e+308L)
> #define __DBL_MIN__ ((double)2.2250738585072014e-308L)
> #define __DBL_EPSILON__ ((double)2.2204460492503131e-16L)
> #define __SIZEOF_DOUBLE__ 8
> 
> Is there something more I should dig out of the logs, or do you know a
> --with-special-float option I can hit it with? (It's a soft float target...)

If you're doing a softfloat target, the ABI musl supports uses 80 bit
long double. --with-arch and --with-cpu should not be needed for the
soft float one since it's 100% compatible with conventional m68k. I'm
guessing either one of those or the -uclinux thing is making gcc
select the different ABI (possibly along with other uclibc/FLAT
oriented things that aren't appropriate with musl).

> I've already got a coldfire kernel booting under qemu with the old toolchain,
> but userspace would NOT do static pie, so I'm down the rabbit hole of building a
> toolchain that's all coldfire static pie...

If something weird is going on with it potentially not loading plain
m68k binaries, I would really start with a known-working-on-cf
userspace and dropping m68k-sf binaries into it, and seeing where they
fail. Otherwise there's going to be a lot of guesswork here since you
can't observe what's going wrong...

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.