Summary: | sys-devel/gnuconfig: mips32-* tuples turned into mips642-* | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | ytrezq |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED INVALID | ||
Severity: | major | CC: | mips |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | MIPS | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
ytrezq
2015-05-15 20:16:02 UTC
CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is one of 'gnu', 'uclibc', or 'musl'. Is your board mips32r1 or mips32r2? I'd pass the full ISA target to -march and -mtune to avoid confusing the compiler as well. mips3-xxx is a valid arch and the gnu config project turns that into mips64-xxx. so when you use mips32-xxx, it changes {mips3}2-xxx into {mips64}2-xxx. as Kumba said, this tuple is invalid. use CFLAGS instead to control the ISA. (In reply to Joshua Kinard from comment #1) > CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is > one of 'gnu', 'uclibc', or 'musl'. Is your board mips32r1 or mips32r2? I'd > pass the full ISA target to -march and -mtune to avoid confusing the > compiler as well. -march=mips32 with -mips32 IN CFLAGS is the only valid way to tell the compiler to generate code for mips32 release 1. It also appear the example here with libcap-ng doesn’t come from the mips642 tuple. (In reply to SpanKY from comment #2) > CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is one of 'gnu', 'uclibc', or 'musl' Maybe, but crossdev requires an argument which need to contain ARCH VENDOR OS LIBC. Though I might used an incorrect vendor, using the desired ISA after mips is the way to specify the target ISA for the generated toolchain. So while it is true I didn’t used mips32-unknown-linux-uclibc, using mips-unknown-linux-uclibc with crossdev would generate a toolchain for a default ISA which is not mips32. (In reply to lcellier from comment #4) crossdev merely tries to provide documentation for the existing tuple standards in a format that is easy to understand. in the end, it simply passes the tuples down to the existing projects (most notably GNU config). crossdev itself imposes no additional requirements on the form of the tuple. if you want to have a toolchain that targets mips32 by default, you could run crossdev with a flag like: ... --genv 'EXTRA_ECONF="--with-arch=mips32"' ... (In reply to lcellier from comment #4) > (In reply to SpanKY from comment #2) > > CHOST for MIPS32r* should be "mips-unknown-linux-<LIBC>", where <LIBC> is one of 'gnu', 'uclibc', or 'musl' > > Maybe, but crossdev requires an argument which need to contain ARCH VENDOR > OS LIBC. > Though I might used an incorrect vendor, using the desired ISA after mips is > the way to specify the target ISA for the generated toolchain. > > So while it is true I didn’t used mips32-unknown-linux-uclibc, using > mips-unknown-linux-uclibc with crossdev would generate a toolchain for a > default ISA which is not mips32. That's just one of the perils with MIPS, unfortunately. The possible mixture of ISAs, ABIs, and Endians just leads to combinatorial explosion. The general rule of thumb is you spin a cross-compiler that matches your bitness (32 or 64), endian, and libc, then pass -mabi, -march, and -mtune to drill down to your preferred target platform. So even though the *default* ISA for mips-unknown-linux-* may not be mips32r1, you can still force that by passing -march=mips32. I myself even learned that you can generate a mips64 compiler and still target all of the available 32-bit userlands out there by passing the correct flags, all thanks to multitarget support in binutils and gcc. In this case, 'mips64-unknown-linux-uclibc -march=mips32 -mtune=mips32 -mabi=32 <flags> <source> -o <binary>' would work for you.
>
> I myself even learned that you can generate a mips64 compiler and still
> target all of the available 32-bit userlands out there by passing the
> correct flags, all thanks to multitarget support in binutils and gcc. In
> this case, 'mips64-unknown-linux-uclibc -march=mips32 -mtune=mips32 -mabi=32
> <flags> <source> -o <binary>' would work for you.
I am very curious on how 32 bits programs can be linked with 64 bits only version crt1.o or crti.o. (I had crti.o no such file or directory)
Or perhaps have you modified your toolchain.eclass so flags aren’t striped?
(In reply to lcellier from comment #7) > > > > I myself even learned that you can generate a mips64 compiler and still > > target all of the available 32-bit userlands out there by passing the > > correct flags, all thanks to multitarget support in binutils and gcc. In > > this case, 'mips64-unknown-linux-uclibc -march=mips32 -mtune=mips32 -mabi=32 > > <flags> <source> -o <binary>' would work for you. > > I am very curious on how 32 bits programs can be linked with 64 bits only > version crt1.o or crti.o. (I had crti.o no such file or directory) > > Or perhaps have you modified your toolchain.eclass so flags aren’t striped? Clarification: I learned this on kernel compiles. Obviously, if you're using a mips64-* compiler and trying to build 32-bit userland stuff, you're going to need a 32-bit libc kicking around. But on kernel runs, you can use a mips64-* toolchain to build 32-bit kernels, as long as you pass -mabi=32.
> Clarification: I learned this on kernel compiles. Obviously, if you're
> using a mips64-* compiler and trying to build 32-bit userland stuff, you're
> going to need a 32-bit libc kicking around. But on kernel runs, you can use
> a mips64-* toolchain to build 32-bit kernels, as long as you pass -mabi=32.
I disagree at least for executables, It tried it myself, as creating executables relies on linking on Crtbegin.o and other files. And you should get compile errors.
There is also some shared libraries like libgcc or libstdxx or libgfortran which can no longer be compiled separately from gcc. and you need a libc for building them (which is why crossdev generate a stage 1, and install kernel headers, then build µClibc, and then build other compiler stages).
You can generate code for any ISA/ABI as long as they don’t rely on external binaries for linking (which is typically the case for the kernel).
Or perhaps it wasn’t modern ELF executables?
(In reply to lcellier from comment #9) i think you're confusing things here. shared libraries are needed only to link, and even then just to link userland code (most of the time). none of that matters to compiling (pure code generation) or linking completely standalone programs like a boot loader or the kernel. it is possible to create a single toolchain that has many multilibs, we just don't generally bother. Gentoo only cares about n32/n64/o32 in the general case. for other ABIs, you have to use your own compiler settings. (In reply to SpanKY from comment #10) > (In reply to lcellier from comment #9) > > i think you're confusing things here. shared libraries are needed only to > link, and even then just to link userland code (most of the time). none of > that matters to compiling (pure code generation) or linking completely > standalone programs like a boot loader or the kernel. > > it is possible to create a single toolchain that has many multilibs, we just > don't generally bother. Gentoo only cares about n32/n64/o32 in the general > case. for other ABIs, you have to use your own compiler settings. Yes I was talking about userland, not the kernel since it in my case the vendor is providing versioned proprietary kernel modules in order to get Linux running on the SoC. I never brought compiling the bootloader or kernel couldn’t be done with a toolchain for an another ABI/ISA since only cc1/lto1 matter in that case (they are not bound to a particular ISA/ABI, and those programs often use custom ld scripts). But for linking userland code, (not for generating .o relocatables) I need the toolchain to be using the same ISA/ABI as the target, which is achieved by using crossdev with ArchIsa-vendor-OS-libc --abis Abi (In reply to lcellier from comment #11) > > But for linking userland code, (not for generating .o relocatables) I need > the toolchain to be using the same ISA/ABI as the target, which is achieved > by using crossdev with ArchIsa-vendor-OS-libc --abis Abi If there's some kind of change floating around out there that alters the CHOST tuple to be <arch><isa>-<vendor>-<kernel>-<libc>, then that's new and we likely won't support it until it becomes more mainstream. We have seen 'mips64-unknown-linux-gnuabin32' before, to generate an n32-only compiler, but we don't support it since a normal 64bit toolchain is adequate for both n32 and n64, provided you build the libc (and other libs) twice for n32 and n64. So in the end, stick with 'mips-unknown-linux-uclibc' for your CHOST tuple and make sure to pass -march=mips32 in CFLAGS/CXXFLAGS/etc, and you should have fewer problems. |