Re: missing gold --be8 support

[Renato Golin]

On 24 May 2016 at 18:13, Peter Smith  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?
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: missing gold --be8 support

[Peter Smith]

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  wrote:
> On 24 May 2016 at 17:05, Jim Wilson  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
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: missing gold --be8 support

[Renato Golin]

On 24 May 2016 at 17:05, Jim Wilson  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

missing gold --be8 support

[Jim Wilson]

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
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week 20

[Yvan Roux]

== Progress ==
o Extended validation (7/10)
   * Investigate GDB instabilities:
 - branch tracing issue are due to builder feature support
 - Our 2 old builders, which don't support it, removed from x86
validation pool
   * Benchmarking:
 - Looked at Lava instance API and lava-tool usage and prerequisite
 - Implementing comparison script

o Misc (3/10)
   * Various meetings and discussions.

== Plan ==
o Continue on validation/benchmarking
o Catch up with upstream work.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain