Cisco is trying to use clang/lto on big-endian arm, which apparently requires gold, and gold does not support the --be8 option which is required for ARMv7 big-endian support. Does anyone here care about this?
Umesh Kalappa asked about this on the binutils mailing list https://sourceware.org/ml/binutils/2016-05/msg00209.html and discovered that it is a known bug reported 5 years ago https://sourceware.org/bugzilla/show_bug.cgi?id=13213
Jim
On 24 May 2016 at 17:05, Jim Wilson jim.wilson@linaro.org wrote:
Cisco is trying to use clang/lto on big-endian arm, which apparently requires gold, and gold does not support the --be8 option which is required for ARMv7 big-endian support. Does anyone here care about this?
Hi Jim,
Using Clang with LTO on ARMv7 is already risky business, since not many people are testing it (we're not), but running it on BE8 is Terra Incognita. We'd have to care about many other things first to get there...
For one, validate BE8, which probably needs QEMU, but we don't have x86_64 hardware where QEMU would be remotely useful. Another, make a decision between implementing LTO in BFD, Gold, or LLD and stick to it, as well as extend to support BE8.
I don't know much about the BFD vs Gold, but I remember that ARM folks weren't happy about relying on Gold for AArch64. Also, LLD has reasonable AArch64 support (mostly only TLS missing), and ARM can (maybe) link (but not run) "hello world" on Peter's development tree, but otherwise doesn't exist.
The best decision, IMHO, would be to have it working on at least one GNU linker and one LLVM linker. The order in which they come doesn't matter.
But that's a year's plan, at least, unless we pick someone to focus solely on that, in which case it could be a few months' plan.
cheers, --renato
Hello,
BE8 support in ARMv7 is independent of LTO. In essence the bit-code file will be code-generated into a big-endian object file. To a linker this is no different to an big-endian ELF object file from the command line or a static library.
I think that the bit missing from Gold is the endian reversal code for instructions, in ARMv7 BE8. If that is implemented then no additional support is needed for LTO. I would suspect that it would be much quicker to implement BE8 support in gold than write a ld LTO plugin.
My understanding is that ld.bfd does support BE8 but there isn't a clang/llvm LTO plugin available for it.
The AARCH64 lld port is little-endian only. I've just started the ARM port downstream, and have started with little-endian support only. As of yesterday I have managed to get hello world working in ARM state only but there is quite a lot to do before lld will become useable in production.
Peter
It is possible to use LTO without a plugin on any linker. There is an executable llvm-lto that wraps libLTO.so. As long as you know which of your input objects are bitcode, and the references that your non-bitcode objects make to the bitcode objects you can simulate the LTO linker plugin. This isn't friendly enough to give to customers but if all LTO is being used for is internal benchmarking it can be good enough.
Not that it is of much use to you, but ARM's proprietary toolchain supports LTO for bare-metal via clang, including v7a, and we (ARM) haven't seen any problems with code-generation due to LTO in the tests that we run.
On 24 May 2016 at 17:27, Renato Golin renato.golin@linaro.org wrote:
On 24 May 2016 at 17:05, Jim Wilson jim.wilson@linaro.org wrote:
Cisco is trying to use clang/lto on big-endian arm, which apparently requires gold, and gold does not support the --be8 option which is required for ARMv7 big-endian support. Does anyone here care about this?
Hi Jim,
Using Clang with LTO on ARMv7 is already risky business, since not many people are testing it (we're not), but running it on BE8 is Terra Incognita. We'd have to care about many other things first to get there...
For one, validate BE8, which probably needs QEMU, but we don't have x86_64 hardware where QEMU would be remotely useful. Another, make a decision between implementing LTO in BFD, Gold, or LLD and stick to it, as well as extend to support BE8.
I don't know much about the BFD vs Gold, but I remember that ARM folks weren't happy about relying on Gold for AArch64. Also, LLD has reasonable AArch64 support (mostly only TLS missing), and ARM can (maybe) link (but not run) "hello world" on Peter's development tree, but otherwise doesn't exist.
The best decision, IMHO, would be to have it working on at least one GNU linker and one LLVM linker. The order in which they come doesn't matter.
But that's a year's plan, at least, unless we pick someone to focus solely on that, in which case it could be a few months' plan.
cheers, --renato _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 24 May 2016 at 18:13, Peter Smith peter.smith@linaro.org wrote:
I think that the bit missing from Gold is the endian reversal code for instructions, in ARMv7 BE8. If that is implemented then no additional support is needed for LTO. I would suspect that it would be much quicker to implement BE8 support in gold than write a ld LTO plugin.
I remember some people not wanting to touch gold with a 10-foot pole, but that might just have been my impression.
I agree that adding BE8 to gold would be easier, but there's a difference between "works on my box" and "Linaro has validated it". I wouldn't want to claim the latter if we only do the former.
Not that it is of much use to you, but ARM's proprietary toolchain supports LTO for bare-metal via clang, including v7a, and we (ARM) haven't seen any problems with code-generation due to LTO in the tests that we run.
Big endian, too?
Not big endian and LTO together that I know of, we have got quite a few bare-metal big-endian tests running on models though.
Peter
On 24 May 2016 at 18:43, Renato Golin renato.golin@linaro.org wrote:
On 24 May 2016 at 18:13, Peter Smith peter.smith@linaro.org wrote:
I think that the bit missing from Gold is the endian reversal code for instructions, in ARMv7 BE8. If that is implemented then no additional support is needed for LTO. I would suspect that it would be much quicker to implement BE8 support in gold than write a ld LTO plugin.
I remember some people not wanting to touch gold with a 10-foot pole, but that might just have been my impression.
I agree that adding BE8 to gold would be easier, but there's a difference between "works on my box" and "Linaro has validated it". I wouldn't want to claim the latter if we only do the former.
Not that it is of much use to you, but ARM's proprietary toolchain supports LTO for bare-metal via clang, including v7a, and we (ARM) haven't seen any problems with code-generation due to LTO in the tests that we run.
Big endian, too?
Thanks for the info. It was about what I expected. I will share the interesting bits with Cisco.
Jim
linaro-toolchain@lists.linaro.org
-
Jim Wilson -
Peter Smith -
Renato Golin