Hello Maxim,
I hit the situation well described in https://gcc.gnu.org/ml/gcc-help/2015-02/msg00029.html , and wonder if there's any updates to your answer since February?
I'm playing with Ubuntu 15.04, on Dragonboard (15.09 Linaro release). Grepping thru output of apt-cache search, I found gcc-4.9-multilib-arm-linux-gnueabi, installed it, which pulled armel and armhf toochains, but didn't change linking behavior of "gcc -mabi=ilp32". Trying to use a arm-linux-gnueabi-gcc-4.9 crosscompiler, it builds executable, but it errors out with "./a.out: No such file or directory" (missing dynamic linker?).
Btw, I had a suspicion that current gcc on that Ubuntu version (gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2), when used with -mapi=ilp32, defines uint64_t to be 4 bytes, and indeed it's true:
#include <stdint.h>
int main() { printf("sizeof(uint64_t)=%d\n", sizeof(uint64_t)); }
gcc -mabi=ilp32 -S uint64.c
... add w0, w0, :lo12:.LC0 mov w1, 4 bl printf ...
Thanks, Paul
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
+++ Paul Sokolovsky [2015-11-12 23:24 +0200]:
Hello Maxim,
I hit the situation well described in https://gcc.gnu.org/ml/gcc-help/2015-02/msg00029.html , and wonder if there's any updates to your answer since February?
I'm playing with Ubuntu 15.04, on Dragonboard (15.09 Linaro release). Grepping thru output of apt-cache search, I found gcc-4.9-multilib-arm-linux-gnueabi, installed it, which pulled armel and armhf toochains, but didn't change linking behavior of "gcc -mabi=ilp32".
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
No! That's a terrible idea. Do you expect -m32 to produce armhf or armel or ilp32 ABI binaries? Why would one make any more sense than the others?
-m32 is a nasty hack IMHO, which works so long as you only have one 32-bit ABI and build multilib tools, but is not a good solution generally: https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib and I donlt think we should copy the mistakes of x86 world in arm world when we can just do it right instead.
If you want binaries of a different ABI, install and use the right cross-toolchain. If you want v7 hardfp binaries then install arm-linux-gnueabihf-gcc-4.9 If you want ilp32 then install aarch64_ilp32-linux-gnu-gcc-4.9 (which you'll have to build first as that's not something we currently build in Debian or Ubuntu, but we could if there was some need)
Then all ABI-specific commands can be triplet-prefixed in order to run the right tools. This works natively and cross
What are you actually trying to do anyway? I thought everyone had given up with ilp32, so we can ignore it? We have patches to make ilp32 behave like a proper ABI, but they are not yet upstreamed because there is no agreed syscall interface for the kernel + glibc to implement: https://wiki.linaro.org/Platform/arm64-ilp32
Wookey
Hello,
On Thu, 12 Nov 2015 22:13:11 +0000 Wookey wookey@wookware.org wrote:
[]
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
No! That's a terrible idea. Do you expect -m32 to produce armhf or armel or ilp32 ABI binaries? Why would one make any more sense than the others?
-m32 is a nasty hack IMHO, which works so long as you only have one 32-bit ABI and build multilib tools, but is not a good solution generally: https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib and I donlt think we should copy the mistakes of x86 world in arm world when we can just do it right instead.
Sure, let's not have all those UEFIs and ACPIs and other mess. No wait, some folks say they will let ARM into "big things" only if those are there ;-). Well, I hope nobody will judge AArch64 by the lack of -m32.
As for what it could mean, many options in gcc are anyway get default values at build time (like -mtune), so -m32 could be set to whatever makes the most sense for particular build. But I'm not advocating it in any way, just trying to apply my previous experience with a 64-bit arch to a new one (my guess is that many "mere" folks would do that, so at least would be nice to have answers ready for them, that's why I cc: 96boards list).
[]
What are you actually trying to do anyway? I thought everyone had given up with ilp32, so we can ignore it? We have patches to make ilp32 behave like a proper ABI, but they are not yet upstreamed because there is no agreed syscall interface for the kernel + glibc to implement: https://wiki.linaro.org/Platform/arm64-ilp32
Well, I compiled an app, it eventually crashed, next logical step (based on x86_64 experience) is to build it in 32-bit mode, to see if it crashes again, or the crash is an artifact of 64-bitness.
Wookey
+++ Paul Sokolovsky [2015-11-13 00:57 +0200]:
On Thu, 12 Nov 2015 22:13:11 +0000 Wookey wookey@wookware.org wrote:
[]
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
No! That's a terrible idea. Do you expect -m32 to produce armhf or armel or ilp32 ABI binaries? Why would one make any more sense than the others?
-m32 is a nasty hack IMHO, which works so long as you only have one 32-bit ABI and build multilib tools, but is not a good solution generally: https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib and I donlt think we should copy the mistakes of x86 world in arm world when we can just do it right instead.
Sure, let's not have all those UEFIs and ACPIs and other mess.
Yeah well, that argument is done already. (and there isn't much wrong with UEFI in fact)
But I'm not advocating it in any way, just trying to apply my previous experience with a 64-bit arch to a new one (my guess is that many "mere" folks would do that, so at least would be nice to have answers ready for them, that's why I cc: 96boards list).
Yes it's quite ingrained in x86-world but it really doesn't make much sense in arm world.
use <triplet>-gcc everywhere (x86 as well) and life will be good.
What are you actually trying to do anyway? I thought everyone had given up with ilp32, so we can ignore it? We have patches to make ilp32 behave like a proper ABI, but they are not yet upstreamed because there is no agreed syscall interface for the kernel + glibc to implement: https://wiki.linaro.org/Platform/arm64-ilp32
Well, I compiled an app, it eventually crashed, next logical step (based on x86_64 experience) is to build it in 32-bit mode, to see if it crashes again, or the crash is an artifact of 64-bitness.
Hmm, OK. You don't want ilp32. It's not finished or useful.
Just build for arm-linux-gnueabihf- .
Some info on crossbuilding on Debian/Ubuntu is here: https://wiki.debian.org/CrossCompiling but it's rather package-oriented. I could add some info on cross-building unpackaged-things if that would be helpful?
Wookey
On Thu, 12 Nov 2015 23:47:27 +0000 Wookey wookey@wookware.org wrote:
[]
But I'm not advocating it in any way, just trying to apply my previous experience with a 64-bit arch to a new one (my guess is that many "mere" folks would do that, so at least would be nice to have answers ready for them, that's why I cc: 96boards list).
Yes it's quite ingrained in x86-world but it really doesn't make much sense in arm world.
use <triplet>-gcc everywhere (x86 as well) and life will be good.
Works for me, thanks.
What are you actually trying to do anyway? I thought everyone had given up with ilp32, so we can ignore it? We have patches to make ilp32 behave like a proper ABI, but they are not yet upstreamed because there is no agreed syscall interface for the kernel + glibc to implement: https://wiki.linaro.org/Platform/arm64-ilp32
Well, I compiled an app, it eventually crashed, next logical step (based on x86_64 experience) is to build it in 32-bit mode, to see if it crashes again, or the crash is an artifact of 64-bitness.
Hmm, OK. You don't want ilp32. It's not finished or useful.
Just build for arm-linux-gnueabihf- .
Some info on crossbuilding on Debian/Ubuntu is here: https://wiki.debian.org/CrossCompiling but it's rather package-oriented. I could add some info on cross-building unpackaged-things if that would be helpful?
Yes, I may imagine that would be helpful. The page you link isn't one I'd look for, I even wonder if that's a thinko and you meant https://wiki.debian.org/CrossToolchains instead. Thanks for arm-linux-gnueabihf- suggestion, as I mentioned in the original email, I tried arm-linux-gnueabi- instead, that built, but didn't run. Unfortunately, few next weeks I don't have access to my Dragonboard, so testing that all will have to wait.
Wookey
+++ Paul Sokolovsky [2015-11-18 16:03 +0200]:
On Thu, 12 Nov 2015 23:47:27 +0000 Wookey wookey@wookware.org wrote:
Some info on crossbuilding on Debian/Ubuntu is here: https://wiki.debian.org/CrossCompiling but it's rather package-oriented. I could add some info on cross-building unpackaged-things if that would be helpful?
Yes, I may imagine that would be helpful.
OK. I need to revist those pages, so will try to add some info on that
The page you link isn't one I'd look for, I even wonder if that's a thinko and you meant https://wiki.debian.org/CrossToolchains instead.
That is the top-level page (about installing toolchains) which links to other docs, including https://wiki.debian.org/CrossCompiling
Wookey
Hi, Wookey
On 11/13/2015 06:13 AM, Wookey wrote:
+++ Paul Sokolovsky [2015-11-12 23:24 +0200]:
Hello Maxim,
I hit the situation well described in https://gcc.gnu.org/ml/gcc-help/2015-02/msg00029.html , and wonder if there's any updates to your answer since February?
I'm playing with Ubuntu 15.04, on Dragonboard (15.09 Linaro release). Grepping thru output of apt-cache search, I found gcc-4.9-multilib-arm-linux-gnueabi, installed it, which pulled armel and armhf toochains, but didn't change linking behavior of "gcc -mabi=ilp32".
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
No! That's a terrible idea. Do you expect -m32 to produce armhf or armel or ilp32 ABI binaries? Why would one make any more sense than the others?
-m32 is a nasty hack IMHO, which works so long as you only have one 32-bit ABI and build multilib tools, but is not a good solution generally: https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib and I donlt think we should copy the mistakes of x86 world in arm world when we can just do it right instead.
If you want binaries of a different ABI, install and use the right cross-toolchain. If you want v7 hardfp binaries then install arm-linux-gnueabihf-gcc-4.9 If you want ilp32 then install aarch64_ilp32-linux-gnu-gcc-4.9 (which you'll have to build first as that's not something we currently build in Debian or Ubuntu, but we could if there was some need)
Then all ABI-specific commands can be triplet-prefixed in order to run the right tools. This works natively and cross
What are you actually trying to do anyway? I thought everyone had given up with ilp32, so we can ignore it? We have patches to make ilp32 behave like a proper ABI, but they are not yet upstreamed because there is no agreed syscall interface for the kernel + glibc to implement: https://wiki.linaro.org/Platform/arm64-ilp32
Not sure if I lost some discussion. I am very interested in ilp32. And rfc2-v6 patches sent out today. Is there any plan to test in linaro? And how do I know the version of patches we supported?
Regards
Bamvor
Wookey
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On 18 November 2015 at 10:21, Bamvor Zhang Jian bamvor.zhangjian@linaro.org wrote:
Hi, Wookey
On 11/13/2015 06:13 AM, Wookey wrote:
+++ Paul Sokolovsky [2015-11-12 23:24 +0200]:
Hello Maxim,
I hit the situation well described in https://gcc.gnu.org/ml/gcc-help/2015-02/msg00029.html , and wonder if there's any updates to your answer since February?
I'm playing with Ubuntu 15.04, on Dragonboard (15.09 Linaro release). Grepping thru output of apt-cache search, I found gcc-4.9-multilib-arm-linux-gnueabi, installed it, which pulled armel and armhf toochains, but didn't change linking behavior of "gcc -mabi=ilp32".
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
No! That's a terrible idea. Do you expect -m32 to produce armhf or armel or ilp32 ABI binaries? Why would one make any more sense than the others?
-m32 is a nasty hack IMHO, which works so long as you only have one 32-bit ABI and build multilib tools, but is not a good solution generally: https://wiki.debian.org/ToolChain/Cross#Multiarch_vs_Multilib and I donlt think we should copy the mistakes of x86 world in arm world when we can just do it right instead.
If you want binaries of a different ABI, install and use the right cross-toolchain. If you want v7 hardfp binaries then install arm-linux-gnueabihf-gcc-4.9 If you want ilp32 then install aarch64_ilp32-linux-gnu-gcc-4.9 (which you'll have to build first as that's not something we currently build in Debian or Ubuntu, but we could if there was some need)
Then all ABI-specific commands can be triplet-prefixed in order to run the right tools. This works natively and cross
What are you actually trying to do anyway? I thought everyone had given up with ilp32, so we can ignore it? We have patches to make ilp32 behave like a proper ABI, but they are not yet upstreamed because there is no agreed syscall interface for the kernel + glibc to implement: https://wiki.linaro.org/Platform/arm64-ilp32
Not sure if I lost some discussion. I am very interested in ilp32. And rfc2-v6 patches sent out today. Is there any plan to test in linaro? And how do I know the version of patches we supported?
there's a work in progress to integrate a mainline kernel with the latest patchset posted, including the user space side (glibc, etc...), using openembedded.
Regards
Bamvor
Wookey
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Hi Paul,
Code for what target exactly are you trying to generate? Is it AArch32 or AArch64+ILP32? The first one is your normal 32-bit-mode-of-execution code. The second one is 64-bit-mode-of-execution with int, long and pointer types set to 32-bit. These are two very different things. To generate code for AArch32 you need to use arm-linux-gnueabi[hf] compiler, and for the second one you need to use aarch64-linux-gnu compiler with -mabi=ilp32 switch (which is still work-in-progress).
Unlike compilers for x86_64-linux-gnu and i686-linux-gnu, which are the same compiler under different names, compilers for aarch64-linux-gnu and arm-linux-gnueabi[hf] are completely different. Therefore there is presently very little chance of having -m32 option for aarch64-linux-gnu compiler.
Does this answer your questions?
-- Maxim Kuvyrkov www.linaro.org
On Nov 13, 2015, at 12:24 AM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello Maxim,
I hit the situation well described in https://gcc.gnu.org/ml/gcc-help/2015-02/msg00029.html , and wonder if there's any updates to your answer since February?
I'm playing with Ubuntu 15.04, on Dragonboard (15.09 Linaro release). Grepping thru output of apt-cache search, I found gcc-4.9-multilib-arm-linux-gnueabi, installed it, which pulled armel and armhf toochains, but didn't change linking behavior of "gcc -mabi=ilp32". Trying to use a arm-linux-gnueabi-gcc-4.9 crosscompiler, it builds executable, but it errors out with "./a.out: No such file or directory" (missing dynamic linker?).
Btw, I had a suspicion that current gcc on that Ubuntu version (gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2), when used with -mapi=ilp32, defines uint64_t to be 4 bytes, and indeed it's true:
#include <stdint.h>
int main() { printf("sizeof(uint64_t)=%d\n", sizeof(uint64_t)); }
gcc -mabi=ilp32 -S uint64.c
... add w0, w0, :lo12:.LC0 mov w1, 4 bl printf ...
Thanks, Paul
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Sun, 15 Nov 2015 14:10:15 +0300 Maxim Kuvyrkov maxim.kuvyrkov@linaro.org wrote:
Hi Paul,
Code for what target exactly are you trying to generate? Is it AArch32 or AArch64+ILP32?
In a reply to Wookey, I elaborated what I tried to do: I had a crash running 64-bit app on Dragonboard, and followed usual cause for diagnosing it by trying to build it in 32-bit mode - by re-applying x86_64 knowledge (and knowledge that ARMv8 is compatible with ARMv7).
While *personally* I'd find it important to know the difference between AArch32 or AArch64+ILP32, wearing a "random 96boards user" hat, I don't really have to, and the only thing I might care is how to build, and run (even if I have just a binary) a 32-bit application. (And then it apparently should be AArch32, to exactly allow a user pick a 32-bit binary they already have, and run it on ARMv8 system).
The first one is your normal 32-bit-mode-of-execution code. The second one is 64-bit-mode-of-execution with int, long and pointer types set to 32-bit. These are two very different things. To generate code for AArch32 you need to use arm-linux-gnueabi[hf] compiler, and for the second one you need to use aarch64-linux-gnu compiler with -mabi=ilp32 switch (which is still work-in-progress).
Unlike compilers for x86_64-linux-gnu and i686-linux-gnu, which are the same compiler under different names, compilers for aarch64-linux-gnu and arm-linux-gnueabi[hf] are completely different. Therefore there is presently very little chance of having -m32 option for aarch64-linux-gnu compiler.
Does this answer your questions?
As for details of internal compiler structuring, it does. But as for 96boards user, it doesn't - there're still no clear, easy, tested instructions how to build/run 32-bit apps. I don't know if you'd consider more or less direct "user support" of 96boards to be your responsibility, but fairly speaking, that's my main concern. That's why I cc: dev@lists.96boards.org - to let the core 96boards team anticipate what kind of questions users may have when they get boards in their hands and see if anything can be done about that (subject to priorities, as of course there're many things to do).
-- Maxim Kuvyrkov www.linaro.org
[]
+++ Paul Sokolovsky [2015-11-18 16:31 +0200]:
On Sun, 15 Nov 2015 14:10:15 +0300 Maxim Kuvyrkov maxim.kuvyrkov@linaro.org wrote:
Hi Paul,
While *personally* I'd find it important to know the difference between AArch32 or AArch64+ILP32, wearing a "random 96boards user" hat, I don't really have to, and the only thing I might care is how to build, and run (even if I have just a binary) a 32-bit application.
there're still no clear, easy, tested instructions how to build/run 32-bit apps. I don't know if you'd consider more or less direct "user support" of 96boards to be your responsibility, but fairly speaking, that's my main concern. That's why I cc: dev@lists.96boards.org - to let the core 96boards team anticipate what kind of questions users may have when they get boards in their hands and see if anything can be done about that (subject to priorities, as of course there're many things to do).
Your feedback has been useful, at least to me. I didn't know that x86 people reached for 'do a 32-bit build' as standard debugging tool, so we need to cater for that tendency, even if it doesn't make that much sense in arm-world.
And I'm a little surprised that you found the obscure/new/unfinished ilp32 info rather than the decade-old arm-linux-gnueabi(hf) standard info. I'm not sure how/where we should be putting info to tell people to use arm-linux-gnueabihf-, because there is already _a lot_ of it online. But your point that this went wrong for you, and no doubt will for others, is useful.
It's also interesting that arm-linux-gnueabi- didn't work for you (did you get an error?) but arm-linux-gnueabihf did. In general I'd expect it not to matter.
Wookey
On Nov 18, 2015, at 5:31 PM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Sun, 15 Nov 2015 14:10:15 +0300 Maxim Kuvyrkov maxim.kuvyrkov@linaro.org wrote:
Hi Paul,
Code for what target exactly are you trying to generate? Is it AArch32 or AArch64+ILP32?
In a reply to Wookey, I elaborated what I tried to do: I had a crash running 64-bit app on Dragonboard, and followed usual cause for diagnosing it by trying to build it in 32-bit mode - by re-applying x86_64 knowledge (and knowledge that ARMv8 is compatible with ARMv7).
While *personally* I'd find it important to know the difference between AArch32 or AArch64+ILP32, wearing a "random 96boards user" hat, I don't really have to, and the only thing I might care is how to build, and run (even if I have just a binary) a 32-bit application. (And then it apparently should be AArch32, to exactly allow a user pick a 32-bit binary they already have, and run it on ARMv8 system).
The first one is your normal 32-bit-mode-of-execution code. The second one is 64-bit-mode-of-execution with int, long and pointer types set to 32-bit. These are two very different things. To generate code for AArch32 you need to use arm-linux-gnueabi[hf] compiler, and for the second one you need to use aarch64-linux-gnu compiler with -mabi=ilp32 switch (which is still work-in-progress).
Unlike compilers for x86_64-linux-gnu and i686-linux-gnu, which are the same compiler under different names, compilers for aarch64-linux-gnu and arm-linux-gnueabi[hf] are completely different. Therefore there is presently very little chance of having -m32 option for aarch64-linux-gnu compiler.
Does this answer your questions?
As for details of internal compiler structuring, it does. But as for 96boards user, it doesn't - there're still no clear, easy, tested instructions how to build/run 32-bit apps. I don't know if you'd consider more or less direct "user support" of 96boards to be your responsibility, but fairly speaking, that's my main concern. That's why I cc: dev@lists.96boards.org - to let the core 96boards team anticipate what kind of questions users may have when they get boards in their hands and see if anything can be done about that (subject to priorities, as of course there're many things to do).
OK, so the answer for a normal user is to use arm-linux-gnueabihf-gcc for compiling 32-bit code and aarch64-linux-gnu-gcc for compiling 64-bit code. There is no option for AArch32/AArch64 similar to x86_64's -m32. The -mabi=ilp32 option of aarch64-linux-gnu-gcc is an advanced topic and should not be used by normal users.
-- Maxim Kuvyrkov www.linaro.org
-
Bamvor Zhang Jian -
Fathi Boudra -
Maxim Kuvyrkov -
Paul Sokolovsky -
Wookey