There's not much to say about this, other than scream and go hide in the
corner. ARM toolchains are just basically fscked.
arm-linux-ld -EL -p --no-undefined -X -o .tmp_vmlinux1 -T
arch/arm/kernel/vmlinux.lds arch/arm/kernel/head.o
arch/arm/kernel/init_task.o init/built-in.o --start-group
usr/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o
arch/arm/common/built-in.o arch/arm/mach-versatile/built-in.o
arch/arm/nwfpe/built-in.o arch/arm/vfp/built-in.o kernel/built-in.o
mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o
crypto/built-in.o block/built-in.o arch/arm/lib/lib.a lib/lib.a
arch/arm/lib/built-in.o lib/built-in.o drivers/built-in.o
sound/built-in.o net/built-in.o --end-group
Produces no error, but:
$ arm-linux-nm ../build/versatile/.tmp_vmlinux1 |grep ' U '
U __divdi3
U __udivdi3
U __umoddi3
Duh.
Result is you get successful kernel builds without any error, but a *bad*
incomplete image. IOW, you do not know whether or not your kernel is
_safe_ to execute.
That's binutils 2.17. binutils 2.16 had this problem and I tried to get a
patch into the kernel to use 'nm' to detect this fsckage. We *need* this
patch in the kernel.
Sam, can we resurrect my attempts to do this please?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On 12/5/06, Russell King <[email protected]> wrote:
> There's not much to say about this, other than scream and go hide in the
> corner. ARM toolchains are just basically fscked.
And while we're on the topic of ARM linux toolchain fsckage, it would
be nice to know what patches and incantations are currently
recommended when configuring gcc for building various modern ARM
kernel/ABI configurations (OABI + soft VFP, EABI, etc.).
There has been some discussion on the crossgcc mailing list,
especially around recent compilers and NPTL/TLS, and crosstool has
accumulated some of the relevant patches. If an expert (i. e.,
someone who has built their own toolchain and gotten an ARM EABI/NPTL
system all the way up) were to reply to this message with some
details, we might be able to coax chip vendors off of hard-float
gcc-3.3/glibc-2.3.x/linuxthreads toolchains.
Cheers,
- Michael
On Tue, Dec 05, 2006 at 03:29:22PM -0800, Michael K. Edwards wrote:
> On 12/5/06, Russell King <[email protected]> wrote:
> >There's not much to say about this, other than scream and go hide in the
> >corner. ARM toolchains are just basically fscked.
>
> And while we're on the topic of ARM linux toolchain fsckage, it would
> be nice to know what patches and incantations are currently
> recommended when configuring gcc for building various modern ARM
> kernel/ABI configurations (OABI + soft VFP, EABI, etc.).
There is no such thing as soft VFP.
I can only talk from the requirements of the kernel. gcc 3.4.3 is
the minimum for ARM, which with binutils 2.17 will allow you to build
the kernel as OABI in *any* configuration. No patches required for
either.
Enabling EABI needs a compiler which supports EABI. That's where I
get fuzzy but recent gcc 4 should be suitable. I have had it suggested
to me that EABI support in the toolchain isn't all that stable at the
moment.
As for userspace... and NPTL, that's a different matter.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Dec 05, 2006 at 07:33:57PM +0000, Russell King wrote:
> There's not much to say about this, other than scream and go hide in the
> corner. ARM toolchains are just basically fscked.
>
> arm-linux-ld -EL -p --no-undefined -X -o .tmp_vmlinux1 -T
> arch/arm/kernel/vmlinux.lds arch/arm/kernel/head.o
> arch/arm/kernel/init_task.o init/built-in.o --start-group
> usr/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o
> arch/arm/common/built-in.o arch/arm/mach-versatile/built-in.o
> arch/arm/nwfpe/built-in.o arch/arm/vfp/built-in.o kernel/built-in.o
> mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o
> crypto/built-in.o block/built-in.o arch/arm/lib/lib.a lib/lib.a
> arch/arm/lib/built-in.o lib/built-in.o drivers/built-in.o
> sound/built-in.o net/built-in.o --end-group
>
> Produces no error, but:
>
> $ arm-linux-nm ../build/versatile/.tmp_vmlinux1 |grep ' U '
> U __divdi3
> U __udivdi3
> U __umoddi3
>
> Duh.
I'm lead to believe that these are due to gcc issuing .globl directives
for these symbols, but not actually referencing them. Hence the symbol
is marked undefined in the symbol table, but no reloations actually
exist.
Hence why the linker (correctly) doesn't fail.
Ergo, no problem. Please ignore the previous mail.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Wed, Dec 06, 2006 at 12:22:26AM +0000, Russell King wrote:
> Enabling EABI needs a compiler which supports EABI. That's where I
> get fuzzy but recent gcc 4 should be suitable. I have had it suggested
> to me that EABI support in the toolchain isn't all that stable at the
> moment.
I use a bog-standard gcc 4.1.0 to cross-compile all my ARM kernels
with, which allows me to build both old-ABI and EABI kernels. (These
days I build all kernels in EABI mode with old-ABI compat.) I have
not run into any code generation issues with this compiler yet.
On the ARM I am running an EABI userland with glibc 2.5, and build
stuff natively with vanilla binutils 2.17.50.0.5 (2.17.5.0.3 is 'too
old', as it doesn't understand the two argument form of the .movsp
directive which one of the gcc ICE fix patches emits), and gcc 4.1.1
with some patches from gcc bugzilla to fix an ICE or two.
On 12/5/06, Russell King <[email protected]> wrote:
> There is no such thing as soft VFP.
Patches have been floating around for quite some time that implement
soft float with VFP parameter passing conventions (which notably
implies native endianness, unlike FPA). They all seem to derive from
Nicolas Pitre's patch at
http://lists.arm.linux.org.uk/pipermail/linux-arm/2003-October/006436.html
, which is said to have some bugs but to supply the majority of the
needed functionality. (See, for instance,
http://www.busybox.net/cgi-bin/viewcvs.cgi/branches/buildroot.mjn3/toolchain/gcc/3.4.6/arm-softfloat.patch.conditional?rev=14854&view=auto.)
I assume that I'm not the first to fix it up for gcc 4.1.1.
> I can only talk from the requirements of the kernel. gcc 3.4.3 is
> the minimum for ARM, which with binutils 2.17 will allow you to build
> the kernel as OABI in *any* configuration. No patches required for
> either.
It would be nice if this appeared prominently in
Documentation/arm/whatever so that vendors who are stuck on gcc 3.3
(and binutils so old that they comment things out in vmlinux.lds) can
be encouraged to move forward.
Cheers,
- Michael
Hello Lennert,
Wednesday, December 6, 2006, 3:08:13 AM, you wrote:
[]
> (These
> days I build all kernels in EABI mode with old-ABI compat.) I have
> not run into any code generation issues with this compiler yet.
I wonder, if OABI-compat is known to actually work on OABI userspace,
I mean, on something real, like xserver-kdrive ;-). Because I'd really
like to build single kernel for both old and new userspace too, but
afraid to try that, fearing to be put down by another broken feature
;-).
--
Best regards,
Paul mailto:[email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Sokolovsky schreef:
> Hello Lennert,
>
> Wednesday, December 6, 2006, 3:08:13 AM, you wrote:
>
> []
>> (These
>> days I build all kernels in EABI mode with old-ABI compat.) I have
>> not run into any code generation issues with this compiler yet.
>
> I wonder, if OABI-compat is known to actually work on OABI userspace,
> I mean, on something real, like xserver-kdrive ;-). Because I'd really
> like to build single kernel for both old and new userspace too, but
> afraid to try that, fearing to be put down by another broken feature
> ;-).
It does work, I routinely switched between softfpa and eabi userspace without reflashing
the kernel. You just need to make sure that both userspace images have the same modules.
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFdnytMkyGM64RGpERAuvpAJ0ccwFvMWQrU1V3THSd1FlaDDwOTACfbj92
+PF+IsXCGxCJx1YThB9NHdQ=
=B7Ff
-----END PGP SIGNATURE-----
On 12/6/06, Paul Sokolovsky <[email protected]> wrote:
> Hello Lennert,
>
> Wednesday, December 6, 2006, 3:08:13 AM, you wrote:
>
> []
> > (These
> > days I build all kernels in EABI mode with old-ABI compat.) I have
> > not run into any code generation issues with this compiler yet.
>
> I wonder, if OABI-compat is known to actually work on OABI userspace,
> I mean, on something real, like xserver-kdrive ;-). Because I'd really
> like to build single kernel for both old and new userspace too, but
> afraid to try that, fearing to be put down by another broken feature
> ;-).
I've used OABI-compat + EABI ARM kernels to routinely switch between
OABI and EABI rootfs boots. There were some minor busybox issues
on the OABI-compat side (w.r.t. syscalls), but nothing major. These
were fairly complex applications, so "it should work" (and IIRC the
patches were publicly available). But I'm sure I'm forgetting some
significant detail and can't go check right now.
>
>
> --
> Best regards,
> Paul mailto:[email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"