No way to use crossdev for building a cross toolchain sparcv8 compliant: the glibc is built using the sparcv8plus ABI. People on #gentoo-sparc told me that sparc32 is not supported anymore in gentoo but, sparcv8 ABI is used in leon VHDL open source processors, which are more and more used in the embedded word. The support for those processors has been included upstream in linux kernel 2.6.33 so it may be a good idea to at least leave a way to build a cross toolchain for that ABI. Reproducible: Always Steps to Reproduce: 1. ABI="sparc32" crossdev -t sparc 2. sparc-unknown-linux-gnu-gcc -mcpu=v8 hello_world.c -o hello_world 3. file hello_world Actual Results: hello_world: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (used shared libs), for GNU/Linux 2.6.18, stripped Expected Results: hello_world: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
Created attachment 234873 [details, diff] Proposed patch to add the feature to common.eblit I don't know at all if it's the right way to proceed, but at least it permits me to create a cross toolchain that is able to cross compile for leon3 processors using sparcv8 ABI.
Comment on attachment 234873 [details, diff] Proposed patch to add the feature to common.eblit i dont want to introduce yet another magic ABI value. the current CHOST munging done by sparc is crap imo (and always has been), but it predates me so ive left it alone. if you want to support a sparcv8 target, then use a CHOST of sparcv8-... perhaps we should take the current magic sparc crap in glibc and only do the munging when the CHOST matches sparc-*. if it doesnt match that, we assume the user is doing something sane ...
(In reply to comment #2) > (From update of attachment 234873 [details, diff]) > i dont want to introduce yet another magic ABI value. the current CHOST > munging done by sparc is crap imo (and always has been), but it predates me so > ive left it alone. > > if you want to support a sparcv8 target, then use a CHOST of sparcv8-... > > perhaps we should take the current magic sparc crap in glibc and only do the > munging when the CHOST matches sparc-*. if it doesnt match that, we assume the > user is doing something sane ... > Yep you're right that would be a better way, but if I'm not wrong, when trying to $ crossdev -t sparcv8-... gcc-stage1 doesn't compile. That's why in the first place I proposed that dirty quirck, maybe the good thing to do would be to fix that compile issue with gcc-stage1, and everything would be good. I'll paste here the build.log as soon as I've reproduced the error, but if I remember well, it was a configure error, where gcc complains that it doesn't know the target sparcv8. If this is the case, would you accept a patch that change the target from sparcv8 or sparc32 to sparc when compiling gcc ?
Created attachment 236039 [details] gcc-stage1 build.log with sparcv8 target
i've finally sat down, absorbed this code, and rewrote it. i think the result should work now -- we do not force sparcv9+ for sparc-* tuples unless your -mcpu settings match. for sparcv7/sparcv8 builds, you probably shouldn't be using something like -mcpu=ultrasparc3, so this should be fine. please let us know if it still fails for you. http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f8a59c05ff00ddafbfbfffecdac6e71cf175fbd
