Re: Q: reasons for lack of support for C++ in OP-TEE?

[Jim Wilson]

On Fri, Aug 11, 2017 at 1:34 PM, Godmar Back  wrote:
> Is this the wrong mailing list to ask the question then?

Perhaps, but maybe you will get a response on Monday from someone in
Europe that didn't see it today.

> Normally, libraries are decomposed into individual .o files to avoid exactly
> this phenomenon where an undefined reference to function X pulls in
> definitions of functions Y, Z, etc. which then cause a chain of dependencies
> to other .o files the linker must resolve.  Is libstdc++ different in this
> respect?
> Because otherwise, features would only be pulled in if required, and that's
> a much more manageable problem.

Yes, of course, if you static link, then you only get the .o files
that you need.  But as I mentioned before, a lot of C++ features
depend on other C++ features.  A simple hello world program compiled
and statically linked is over 2MB.

palantir:2089$ cat tmp.cc
#include 

int
main (void)
{
  std::cout << "Hello world\n";
  return 0;
}
palantir:2090$ g++ -static tmp.cc
palantir:2091$ ls -lt a.out
-rwxrwxr-x 1 wilson wilson 2181416 Aug 11 14:03 a.out
palantir:2092$

We can see all of the object files being pulled in if we pass the
--verbose option to the linker.  There are 92 of them.

palantir:2092$ g++ -static tmp.cc -Wl,--verbose | grep libstdc
attempt to open /usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a succeeded
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)ios_init.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)globals_io.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)ios-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)ext11-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)ostream-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)wlocale-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)ios.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)cow-wstring-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)istream-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)functexcept.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)cow-stdexcept.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)streambuf-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_throw.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_exception.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_personality.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)del_op.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_catch.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_aux_runtime.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)bad_typeid.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)bad_cast.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)si_class_type_info.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_call.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)new_opv.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)pure.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)tinfo.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)class_type_info.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)new_op.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)new_handler.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)vmi_class_type_info.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)del_opv.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_alloc.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_terminate.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)eh_globals.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)bad_alloc.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)dyncast.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)locale.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)istream.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)locale_facets.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)time_members.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)locale_init.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)stdexcept.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)c++locale.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)monetary_members_cow.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)numeric_members.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)basic_file.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)ios_locale.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)streambuf.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)messages_members_cow.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)numeric_members_cow.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)codecvt.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)cow-istream-string.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)codecvt_members.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)collate_members_cow.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)ctype.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)string-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)cxx11-locale-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)locale-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)cxx11-wlocale-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)cow-string-inst.o
(/usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a)snprintf_lite.o

Re: Q: reasons for lack of support for C++ in OP-TEE?

[Jim Wilson]

On Fri, Aug 11, 2017 at 6:53 AM, Godmar Back  wrote:
> In a recent github thread
>  it
> was suggested that I ask this list about what the exact reasons for the
> lack of C++ support are, and how/if they break down by C++ feature so as to
> gauge a possible investment in remedying this situation at least partially.

Answering this question would required detailed knowledge of OP-TEE,
and I doubt that anyone on this list has such knowledge.  I was just
reading some FAQs about OP-TEE myself.

I would guess that part of the problem is that libstdc++ is so large,
and isn't designed to be pulled apart into small pieces, as there are
a lot of features that interact with other features.  Just running nm
on libstdc++.so, and grepping for GLIBC_, I see that it calls 105
glibc functions.  Some of these functions are I/O related and are
obvious problems, like fopen, fclose, fread, fwrite.  Some of them are
clock related and could be an issue, like clock_gettime, gettimeofday.
The string and memory routines are probably OK, but libstdc++ may be
using more of them than OP-TEE implements.  There are also a lot of
wide-character and multi-byte character routines being used that may
not be available.  There are pthread related functions that may or may
not be a problem.  There are also some environment and locale related
routines that are likely a problem, but maybe you can just provide a
default environment and locale.

Otherwise, I don't know enough about OP-TEE to guess what might be a
problem.  The exception handling support just requires the ability to
read your own process memory, including the stack, the unwind info,
and the ELF headers that get loaded into memory at program start.  I
don't know if that is a problem for OP-TEE.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Problems with Aarch64 vmull_p64 and vmull_high_p64

[Jim Wilson]

On Sun, Jul 30, 2017 at 4:47 PM, Jeffrey Walton  wrote:
> The odd thing is, ARM's ACLE [1], Section 6.5.4 (p.24),  states Crypto
> applies to
> AES{E, D} and SHA1{C, P, M}. It does not mention PMULL. Later it goes
> on to state PMULL gear is available on Aarch32 and Aarch64.

If you look at the ARMv8 Architecture Reference Manual, section A1.6
Cryptographic Extension, it says
"Large polynomial multiplies are included as part of the Cryptographic
Extension, see PMULL, PMULL2 on
page C6-1096."

If you look at section C6.3.190 PMULL, PMULL2, it says
"The '1Q' arrangement is only allocated in an implementation that
includes the Crypto extensions,
and is otherwise RESERVED."

So pmull.8b is always valid, but pmull.1q is only valid on targets
that support the Crypto extensions.

Looking at the ACLE docs, section 6.5.7 says AES, SHA1, etc.  The etc
would include things like pmull and sha256.

I see in section 12.3.14 Crypto Intrinsics, it mentions vmull_p64 and
vmull_high_p64, but this being part of the crypto intrinsics section,
it seems clear that they are part of the crypto extension.  It does
also mention that they are available for AArch32 and AArch64; this
part is odd.  All of the crypto instructions appear to be available
for both AArch32 and AArch64, so it isn't clear why this is explicitly
mentioned for pmull.  This statement appears unnecessary, and
potentially confusing.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Problems with Aarch64 vmull_p64 and vmull_high_p64

[Jim Wilson]

On Sun, Jul 30, 2017 at 1:32 PM, Jeffrey Walton  wrote:
> hikey$ g++ -march=armv8-a test.cxx -c
> test.cxx: In function ‘poly128_t VMULL_P64(poly64_t, poly64_t)’:
> test.cxx:10:1: error: unrecognizable insn:

pmull is part of the crypto extension, which is not enabled by
default.  You need to use -march=armv8-a+crypto.  Or else specify a
-mcpu= option for a cpu that has the crypto support.  However, not all
cortex-a53 processors support the crypto extension, so
-mcpu=cortex-a53 is not safe, though this will work accidentally in
some older gcc versions, possibly including your compiler, depending
on which patches have been backported to it.  -mcpu=cortex-a53 will
definitely not work in current compiler versions.

If you use a compiler version that supports the crypto intrinsics,
then you will get slightly less confusing error message complaining
about a target specific option mismatch, as the intrinsics are defined
to require crypto support.

There may also be other issues here, but this seems to be the immediate one.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Error: unknown pseudo-op: `.arch_extension'

[Jim Wilson]

On Wed, Apr 19, 2017 at 11:35 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
> On Wed, Apr 19, 2017 at 9:57 PM, Jim Wilson <jim.wil...@linaro.org> wrote:
>> On Wed, Apr 19, 2017 at 12:38 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
> The thing I am not sure about is saving and restoring the cpu. The AS
> manual states "Specifying .cpu clears any previously selected
> architecture extensions". But arch_extensions does not seem to work,
> so I guess its a moot point. Also, the manual only discusses '.set' in
> the context of MIPS. The program below does not produce a warning or
> error. I am not sure if its doing what's expected.

For a non-mips target, .set is the same as .equ and =, it sets a
symbol value to an expression.  Your code using .set push and .set pop
isn't doing anything useful.

I don't see any mechanism in the assembler to save/restore a cpu
setting.  There is one in gcc, but not until gcc 6.

I don't see any easy solution for you at the moment, you need a
binutils/gcc upgrade, or you need to put crc code in separate files.
Or you could force all files to be compiled with -mcpu=generic, and
then you can use .cpu to add/remove crc support as necessary.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Error: unknown pseudo-op: `.arch_extension'

[Jim Wilson]

On Wed, Apr 19, 2017 at 12:38 PM, Jeffrey Walton  wrote:
> According to [1], I can use ".arch_extension" to enable it. According
> to [2], ".arch_extension" is available in GCC 4.6 and GAS 2.21. My
> version of Linaro provides GCC 4.9.2 and GAS 2.25.90. I can also
> duplicate the issue on GCC113 (compiel farm), which provides GCC 4.8
> and GAS 2.24.

ARM is a little ambiguous.  It turns out that arch_extension was added
to the arm (32-bit) port in 2010, but wasn't added to the aarch64
(64-bit) port until 2014.
So you need binutils-2.26 in order to use arch_extension pseudo-op
with the aarch64 toolchain.

Meanwhile, you might try looking at the arm_neon.h header file for
your gcc version.  Though it apperas in gcc-4.9.2 there is only a
predefined macro __ARM_FEATURE_CRYPTO that you can use, and nothing
for CRC.  GCC 5.x adds a __ARM_FEATURE_CRC32 predefined macro that you
could use.

With gcc 6, the arm_neon.h file uses
#pragma GCC push_options
#pragma GCC target ("+nothing+crypto")
...
#pragma GCC pop_options
to enable crypto support.  You can do something similar with crc, you
probably want to use "+onthing+crc" if you only want crc support
enalbed, or "+simd+crc" if you want both simd and crc support enabled
for instance.

The GCC aarch64 port does not use the arch64_extension support in binutils.

I think the linux kernel just puts functions that need crc support in
different files, so that those files can be compiled with crc support
enabled via -mcpu=generic+crc.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: v8.2-A CPU support

[Jim Wilson]

On Tue, Feb 21, 2017 at 11:34 PM, David Xia  wrote:
> Please check:
> https://gcc.gnu.org/gcc-7/changes.html , it says, start to added 
> -march=armv8.2-a. Does it mean gcc-6.2 NOT support this option?
>
> So does the 'gcc-linaro-6.2.1-2016.11' add the same option? However, the 
> release comes from gcc-6.2. I am a little confused? Does this release fully 
> support aarch64 (ignore some bug fix)? If yes, this should be one good choice 
> for the customer. Thanks.

We backport patches from the FSF development tree into our releases.
So the linaro gcc-6.2 has more arm/aarch64 features than the FSF
gcc-6.2.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: v8.2-A CPU support

[Jim Wilson]

On Tue, Feb 21, 2017 at 11:04 PM, David Xia  wrote:
> Thanks for the information. I have checked the release notes which says GCC 
> 6.2 NO support on v8.2-A. So I would like to know when will v8.2-A support 
> would be added? Or the Linaro member could get the internal release for that 
> (Just guess)? Thanks

It looks like the v8.2 support was complete in the FSF sources in Sept
2016, backported to Linaro sources in Oct 2016, and is present in
gcc-linaro-6.2.1-2016.11 and later releases.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: ABE patching

[Jim Wilson]

On Thu, Feb 16, 2017 at 3:27 AM, Fathi Boudra  wrote:
> On 16 February 2017 at 06:12, Denys Dmytriyenko  wrote:
>> I was wondering if there was a way to apply local patches to toolchain
>> components (gcc, binutils, glibc, etc.) when building with ABE.
>>
>> The only way I know of right now is to mirror the upstream repository into 
>> own
>> git tree, patch it and point ABE to it; or check it out locally, patch it and
>> pass the resulting tarball to ABE build with --disable update flag.

The normal way for tcwg to use abe is to create a git branch, and then
point abe at the git branch.  This is how gerrit patch reviews work
for instance.  Presumably only tcwg members can create git branches in
the tcwg git tree, but anyone can mirror it in a local git repo and
create local branches, which is what I do.

tcwg has no need for abe to support builds with patches in the source
tree, so is unlikely to implement this feature.  If patch support was
added, it should be enabled by an extra option, so that we don't risk
accidentally breaking release builds.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Compiler selection for log10/Qsort on ARM64

[Jim Wilson]

On Tue, Feb 7, 2017 at 7:50 AM, Bharat Bhushan
 wrote:
> I am working on log10/qsort benchmarks on ARM64 (ARMv8) processor,
> I want to check if we have experience with these benchmarks.

We have experience with things like SPEC and Coremark, which are
compiler performance benchmarks.  log10/qsort sounds like glibc
functions.  Are you testing glibc performance?  That would perhaps
depend more on the glibc version than the compiler version.

> Actually i am looking for a compiler version which gives best results with
> these benchmarks and specific compiler optimization (in my case is see O3
> gives best numbers) ?

What exactly are you trying to optimize?  If you want best performance
for your application, then you try every compiler version and every
option and use the combination that gives the best performance.  Us
toolchain developers only care about performance of the latest
version, and if it isn't the best performing one, then we try to fix
it.  If you want best performance for the most people, then you
concentrate on -O2 results as that is what most people use.  I can't
give a better answer without more specifics of what exactly you are
trying to do.

> I have tried GCC-4.9 and GCC-6.2 with log10 benchmark and my observations
> are:
> 1)  With gcc 4.9-   140 us
> 2)  With GCC 6.2   -   150 us
> My compilation flags are "-O3 -ftree-vectorize -funroll-all-loops --param
> max-inline-insns-auto=550 --param case-values-threshold=30
> -falign-functions=32 -ftracer"
>
> So it seems like gcc-6.2 is better, am i missing something, should i use
> some better compiler flags?

Usually for benchmarks, a faster runtime is a better result, so it
looks like gcc-4.9 is giving the better result.  If that is a gcc-6
bug, then it should be reported so we can try to fix it.  However, you
are using a lot of options, and some of those options aren't the
default because they don't always give the best results.  The
usefulness of some uncommon optimization options can vary from one gcc
release to the next.  You may need to use different sets of gcc
options with different gcc versions to get the best results.  But
again, as mentioned above, this all depends on what exactly you are
trying to do, and you haven't given us enough info to understand that.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Does Linaro's GCC 4.9 include Crypto extensions and intrinsics?

[Jim Wilson]

On Thu, Jan 12, 2017 at 10:55 PM, Jeffrey Walton  wrote:
> Does Linaro's GCC 4.9 provide AES and SHA intrinsics?

Crypto is an optional feature that is not enabled by default when
selecting the armv8-a architecture.  You either need to specify a
processor that implements the crypto extension, or else you need to
specify the crypto extension when specifying the architecture.  The
latter is probably easier.  For instance, you can do
-march=armv8-a+crypto to enable the crypto support.  You can also
enable crc support by adding "+crc", separately, or in combination
with +crypto.

> $ grep -IR vaeseq_u8 /usr/include
> /usr/include/clang/3.5.0/include/arm_neon.h:__ai uint8x16_t
> vaeseq_u8(uint8x16_t __p0, uint8x16_t __p1) {
> ...

GCC specific header files are normally not in /usr/include.  On my
Ubuntu 14.04 system, it is
/usr/lib/gcc/aarch64-linux-gnu/4.8/include/arm_neon.h
and vaeseq_u8 is in there, but only enabled when crypto support is enabled.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Compiling linaro tool chain in cygwin

[Jim Wilson]

On Sat, Oct 29, 2016 at 1:49 AM, 李康  wrote:
> Is there any instruction / manual for compiling linaro tool chain under
> cygwin?

We do our windows mingw32 builds under Linux, using cross compilers.
We don't do builds on windows.  In theory, a build should work under
cygwin as they work on linux, but we don't test that.  In practice,
you might run into a few issues that will need to be worked around.

We use a tool called ABE for building toolchains.  You can find info on ABE here
https://wiki.linaro.org/ABE

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: AArch64: Disabling conditional execution

[Jim Wilson]

On Tue, Sep 20, 2016 at 8:07 AM, Fernando Endo  wrote:
> I'm using Linaro GCC 4.9-2015.01-3 for AArch64, and trying to disable the
> generation of guarded instructions. More specifically, I'd like not to see
> instructions such as 'cset', 'csinc', 'ccmp', 'fccmp', etc.

There are a lot of different optimization passes that can generate
these instructions, and probably not all of them can be disabled via
options.  A better approach would be to disable the patterns that
generate the conditional move instructions.  The compiler should still
work without them.  In the gcc/config/aarch64/aarch64.md file, you
want to disable all of the patterns after the comment

;; ---
;; Store-flag and conditional select insns
;; ---

and before the Logical operations comment.  You can disable a pattern
by modifying the first set of quotes from "" to "0", or if there is
already code there, change it to "0 && ..." where ... is the original
code.  Or alternatively, you can just delete all of the patterns.  I
see that there is one crc pattern mixed in among the csel patterns,
which is an odd place for it.  That one should not be touched, though
it is only used if the code being compiled calls one of the crc
builtin functions, which is uncommon.

For the conditional compare instructions, this is a little more
complicated.  You need to disable or delete the cbranchcc4,
ccmp, fccmp, and fccmpe patterns in the aarch64.md
file.  And you also need to delete the #undef and #define in aarch64.c
for TARGET_GEN_CCMP_FIRST and TARGET_GEN_CCMP_NEXT.

If you want a more useful patch, you can add a compiler option, and
then make all of the patterns conditional on the compiler option, so
that they can be turned off and on via the command line instead of
needing two different compilers.

I haven't tried this myself, so there could be some issues that I
overlooked.  I would expect this to work though.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Question on "Using deprecated CP15 barrier instruction".

[Jim Wilson]

On Mon, Sep 5, 2016 at 8:10 AM,   wrote:
> There is a Linux kernel file "arch/arm64/kernel/deprecated.c". Within that
> file is a block of code which is apparently designed to detect some sort of
> older obsolete 32-bit code. Specifically, the warning message is "Using
> deprecated CP15 barrier instruction".

I assume this is the same file as armv8_deprecated.c in the linux 4.0
sources I have.  The file provides code to emulate deprecated
instructions.  You can emulate a deprecated instruction if you catch
the illegal instruction trap that was generated, and then call some
emulation code instead of sending a signal to the program.  The
emulation code prints a warning to let you know that you have some
very old code that really should be re-compiled.  That is the point of
the emulation.  it isn't to handle any code generated by the current
compiler for current targets, but rather code generated by an old
compiler or for old targets that is using instructions that have since
been deprecated.

It appears that you need to use an armv6 compiler to get the cp15
barrier instruction, which was deprecated in favor of the new dmb/dsb
instructions in armv7.

Since these are memory synchronization barriers, you can get them from
C code, but only if you are doing something special, like calling the
old sync built-ins or the new atomic built-ins, or using a compiler
feature that will cause these builtins to be called automatically such
as a feature that uses thread support or coroutines or some similar
feature.

There is no synchronization support in gcc-4.3.  Looking at the
gcc-4.4 arm support, I see that there are two special instructions for
getting memory synchronization support from the kernel.
#define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0x0fc0)
#define __kernel_dmb (*(__kernel_dmb_t *) 0x0fa0)
It appears that reading from a protected memory location is somehow
triggering the kernel support.  In gcc-4.7, the sync intrinsics were
rewritten, and here I see that gcc is now emitting dmb for armv7 and a
cp15 barrier for armv6.  The current support is the same.

So you can get a cp15 barrier from the current compiler, but you need
to compile for armv6, and directly or indirectly call the
synchronization and/or atomic builtins.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: gcc-linaro-6.1-2016.07...Big Endian and Little Endian aarch64 Options

[Jim Wilson]

On Sun, Aug 21, 2016 at 3:07 PM,   wrote:
> also have some prebuilt 5.2 and 5.3 binaries, plus a few other 4.8 and 4.9
> compilers from quite some time back. I've used these for building a Linux
> 3.10 kernel, and the newer linaro-6.1 fails during kernel compile. The issue
> seems to be the assembler does not recognize option "-EL" (all of the ARM
> systems I'm building for are little endian, I've not seen a big endian
> system).

Embedded toolchains are frequently multilibbed for big/little endian,
but linux toolchains are not.  There is no convention for having both
big and little endian glibc installs on a system, and no convention
for having both big and little endian system call entry points in the
kernel.  So for a linux toolchain, you have to choose whether it is
big or little at configure time with the target triplet, and you can't
change it after configure time.  arm is little endian by default, and
armeb is big-endian.  Similarly, aarch64 is little endian and
aarch64_be is big-endian.

If you are getting assembler errors for -EL and/or -EB, then you
probably aren't using an arm/aarch64 assembler.  You are probably
accidentally using an x86 assembler instead.  Try adding a -v option
to the gcc command to check what assembler is being used, and try
adding a -Wa,v option to get verbose info from the assembler which
will tell you what it was configured for.

You mentioned earlier that you didn't bother building binutils, this
might be why gcc is failing after the install.  Binutils is pretty
easy to configure and build compared to gcc, and bugs in binutils are
rare compared to gcc, so there is no reason to skip the binutils build
when doing a toolchain build.  This is likely to cause more problems
than it avoids.  Just be sure to use the same configure options for
binutils that you use for gcc, and configure/build/install binutils
before you configure/build/install gcc.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question

[Jim Wilson]

On Sat, Aug 20, 2016 at 7:38 PM,   wrote:
> The whole cross-architecture situation complicates things...in particular
> I'm wondering "which" binutils (host versus target sysroot) we are talking
> about? I'm trying to figure out if the missing binutils is from the armhf
> sysroot or from the x86_64 host I'm building on. There is an armhf
> binutils-dev package on the armhf build sysroot, and binutils-dev package on
> the aarch64 build sysroot (both the armhf and aarch64 sysroots include
> everything needed to build, link, and develop for their particular
> architecuture on the systems they were cloned from).

The assembler in the sysroot is an armhf binary, which won't run on
the x86_64 host (well, maybe with QEMU but that isn't the right
approach).  You need a x86_64 cross to armhf binutils on the host.
You apparently don't have one.

Normal process is to configure/build/install binutils first, and then
configure/build/install gcc, using the same configure options for
binutils and gcc, in particular prefix and sysroot.  A cross gcc can't
be built without a cross binutils.  A cross binutils doesn't have
dependencies on anything else.  So binutlis has to be built first.

> The x86_64 host has native packages for everything, but in a few cases has
> some cross-architecture packages. "as" is missing according to the
> config.log, but the assembler is present for native x86_64 and aarch64
> cross-assembling. Would it be correct that the missing packages are
> cross-architecture armhf needing to be installed on the x86_64 host, and
> that build sysroot is unrelated to the missing package? It seems I probably
> need x86_64 host binutils cross-assembling to armhf.

Yes, if you are on a debian/ubuntu host, then installing the
gcc-arm-linux-gnueabihf package might be sufficient to get the cross
binutils that you need.

> If I need to build cross-binutils and such, is there any reason to not use
> pre-compiled binaries from Linaro 5.2 or 5.3 tool chains?

You could try this, but it might end up a bit awkward.  GCC needs to
be able to find the assembler both at build time, and at run time.
The normal way this works is that binutils and gcc must be configured
with the same prefix.  If you use an assembler from a linaro
toolchain, it might not be the same prefix.  Perhaps you can arrange
to install your gcc build over top the linaro binutils binaries, so
that the prefix can be the same.

Yes, building cross compilers is complicated.  It takes some time to
learn how to do it.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question

[Jim Wilson]

On Thu, Aug 18, 2016 at 7:50 PM,   wrote:
> /home/build/linaro/32bit/./gcc/as: line 106: exec: -m: invalid option
> exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection
> ...]

The libgcc config.log is the right one to look at.  The error is here,
when gcc calls the assembler, the assembler gives an error.  So
something is wrong here.  You need to configure, build, and install
binutils before you configure and build gcc, using the same configure
options for binutils and gcc.

To look at this a bit more, you can cd into the gcc build dir and try
  touch tmp.c
  ./xgcc -B./ -v tmp.c
which will show the options passed to the assembler, and what
assembler binary is being used.

You probably also want to look at the as file in the gcc build dir,
which should be a shell script pointing at the installed assembler.
This shell script is created at gcc configure time.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: stdc-predef.h failed during gcc-linaro-snapshot-6.1-2016.07 compile

[Jim Wilson]

On Sun, Aug 14, 2016 at 8:29 PM,   wrote:
> One sample configure I'm trying, where "/mnt" is a loopback mounted clone of
> the aarch64 system:
> ${SRC}/configure
> --prefix=/usr/local/aarch64-linux-gnu/gcc-linaro-6.1-2016.07
> --target=aarch64-linux-gnu \
>  --with-build-sysroot=/mnt \
>  --enable-languages=c,c++ \
>  --includedir=/mnt/usr/include

The problem here is that you are using --with-build-sysroot but not
--with-sysroot.  --with-sysroot enables support for sysroots.
--with-build-sysroot changes the sysroot value used during the build,
but does not itself enable sysroot support.  So using
--with-build-sysroot without --with-sysroot is useless.  This is
mentioned in the install docs.  You can specify --with-sysroot=/ to
enable sysroot support, without specifying an alternative host sysroot
dir.  That makes the build succeed.

I think the --includedir option here is useless.  includedir is
supposed to be for the dir where gcc header files are installed, which
is not /usr/include, but rather $prefix/include.  This should not be
necesary but appears to be harmless.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: stdc-predef.h failed during gcc-linaro-snapshot-6.1-2016.07 compile

[Jim Wilson]

On Sat, Aug 13, 2016 at 3:17 PM,   wrote:
> I've been trying to build the c and c++ cross-compiler for triplet
> aarch64-linux-gnu (--target=aarch64-linux-gnu --enable-languages=c,c++) on
> snapshot for 6.1-2016.07, and cannot get past this:
> cc1: error: no include path in which to search for stdc-predef.h

stdc-predef.h is a glibc header file that defines macros that the ISO
C standard requires that the compiler define by default.  So gcc
includes the file by default for linux targets, unless you use
-ffreestanding or -nostdinc.  The real problem here is that you are
apparently trying to build a cross compiler without glibc, and that
doesn't work.  Glibc is required for the compiler build when building
for a linux target.

If you have a target OS that already has a userspace filesystem, then
you can create a sysroot that contains /lib, /usr/lib, /usr/include
(and other library dirs if they exist), put a copy on the machine
where you are doing the compiler build, and then use a --sysroot
configure option to point at the sysroot.  This also requires that
binutils is configured with the same --sysroot option.  If you don't
care about the target OS, you could grab one of the sysroots that the
tcwg team builds and releases.

Alternatively, you can build gcc and glibc at the same time.  This is
complicated, because of the circular dependencies between gcc and
glibc, so it is best to use a script.  Linaro uses ABE for toolchain
builds.
   https://wiki.linaro.org/ABE
But there are other choices, like crosstools-ng and Open Embedded.

I wouldn't recommend modifying gcc sources to work around this, as
then you will get a compiler that doesn't fully conform to the ISO C
standard.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: vreinterpretq_*_p128 for converting from polynomials?

[Jim Wilson]

On Fri, Jul 29, 2016 at 7:55 PM, Jeffrey Walton  wrote:
>> Yes, these *p128* intrinsics are missing from the aarch64 port.  I'd
>> suggest filing a bug report.
>
> Please forgive my ignorance. Who gets the report? Linaro, Debian or GCC?

The FSF GCC bugzilla.
https://gcc.gnu.org/bugzilla/
You need an account to file a bug, and if you don't already have one,
you might not be able to file a bug report at the moment as we
temporarily disabled account creation to deal with a spam attack, and
I don't know if that has been turned back on.  If this is too much
trouble, I can file a bug report for you.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Compile error when building an Aarch32 program on Aarch64?

[Jim Wilson]

On Fri, Jul 29, 2016 at 7:04 PM, Jeffrey Walton  wrote:
> How does one build an Aarch32 program on Aarch64?

The arm and aarch64 compilers are separate compiler ports.  So you
need two different compilers, an arm compiler and an aarch64 compiler.
The arm compiler emits only 32-bit code.  The aarch64 compiler emits
only 64-bit code.  The native compiler is an aarch64 compiler.  I
don't think that we ship arm cross compilers for that.  You could try
to build one but this isn't the solution I would recommend.  If you
have ubuntu, then there is a gcc-arm-linux-gnueabihf package you can
install.  Note that aarch64 systems don't have mutlilib/multiarch
support yet like i686/x86_64 systems.  At least not Ubuntu 14.04LTS
trusty and Debian Jessie.  If you static link, you might get arm code
working in an aarch64 environment, but you won't be able to do much
with it.

This works much better if you install an arm userspace via
debootstrap, chroot into the arm userspace, and then compile code.
The arm userspace will have a native arm compiler.  I have this setup
on a dragonboard (jessie) and an APM Mustang (trusty) and it works
fine.  lxc/lxd also works on my trusty system, but I mostly use
schroot.  A hikey doesn't have as much disk/flash space as my
dragonboard though, so this might not be as convenient.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: vreinterpretq_*_p128 for converting from polynomials?

[Jim Wilson]

On Thu, Jul 28, 2016 at 8:36 AM, Jeffrey Walton  wrote:
> I'm having trouble finding vreinterpretq_u64_p128 (and friends) to
> help convert a polynomial. I can't find it in arm_neon.h or
> arm_acle.h:

> An RPI-3 with ARMv8/Aarch32 and GCC 4.9.2 has it in arm_neon.h:

Yes, these *p128* intrinsics are missing from the aarch64 port.  I'd
suggest filing a bug report.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

[Jim Wilson]

On Thu, Jul 21, 2016 at 9:13 PM, Jeffrey Walton  wrote:
> So I guess the question is, what do I use for -mfpu=neon-vfp3 (or
> -mfpu=neon-vfp3-d32)? Is -mfpu=neon enough?

The -mfpu=neon option is enough.  neon implies vfpv3 and 32 D registers.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

[Jim Wilson]

On Thu, Jul 21, 2016 at 8:48 PM, Jeffrey Walton  wrote:
> Is there an arm-msr-tools or similar that has setuid so we can access the 
> MSRs?

I'm not familiar with any such tool, but I haven't looked for one
before.  I found an x86 msr-tools project at github with a web search.
It seems to be a standard part of debian/ubuntu x86 distros.  I don't
see an obvious arm equivalent.

You could ask the kernel developers to add a hardware capability
(hwcap) check for half-precision fp and emit that info into the
/proc/cpuinfo file, though it would take a while for that to be
implemented and propagate to your users.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: What -mfpu option is used with neon, vfpv3 and vfpd32 flag?

[Jim Wilson]

On Thu, Jul 21, 2016 at 6:33 PM, Jeffrey Walton  wrote:
> I think vfpd32 cpu flag means I have 32 D-registers. The cpu flags
> neon and vfpv3 flags means I want something more than -mfpu=neon-fp16,
> but I'm not sure what that is.

neon implies vfvp3 and 32 D-registers and asimd/neon support, so that
part is correct.  it isn't obvious to me if you have the
half-precision float support.  The "half" printed by the kernel means
that half-word loads are supported, which is only false for some
obsolete parts I think.  The kernel doesn't appear to be checking to
see if the hardware has half-precision float support or not, so you
can't determine that from /proc/cpuinfo.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: -mfpu=neon-fp-armv8 and unrecognized command line option

[Jim Wilson]

On Thu, Jul 21, 2016 at 1:53 AM, Richard Earnshaw
<richard.earns...@arm.com> wrote:
> On 20/07/16 22:33, Jim Wilson wrote:
>> On Wed, Jul 20, 2016 at 2:14 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>>> I'm having trouble with ARMv8/Aarch64. One is an early Mustang server
>>
>> ARMv8 implies 32-bit code (aarch32).  Aaarch64 implies 64-bit code.
>> These are two different compilers, with two different sets of command
>> line options.
>
> Er, no.  ARMv8 (pedantically ARMv8-A, since there are also ARMv8-R and
> ARMv8-M specifications as well) is an architecture, not an ISA.

I think you are confusing the issue.  We are talking about gcc here,
not ARM documentation.  In gcc, arm* means 32-bit code.  An
armv8-linux-gnu compiler is a 32-bit compiler.  If I run uname -a, and
see armv8a, I have a 32-bit user space.  Etc.

The original poster is well aware that ARMv8 is an architecture, with
32-bit and 64-bti execution modes.  What he wasn't aware of was that
the arm and aarch64 compilers are separate, and that if someone
mentions an armv8 compiler on a gcc mailing list, then they are
talking about the 32-bit arm* compiler, not the 64-bit aarch64
compiler.

I did mention that both the arm and aarch64 compilers can emit ARMv8
architecture code.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: -mfpu=neon-fp-armv8 and unrecognized command line option

[Jim Wilson]

On Wed, Jul 20, 2016 at 3:04 PM, Jeffrey Walton  wrote:
> Thanks Jim. According to ARM, ARMv8 is 64-bit
> (http://www.arm.com/products/processors/armv8-architecture.php). Maybe
> I'm parsing the page incorrectly?

The armv8 architecture spec has both aarch32 (32-bit) and aarch64
(64-bit) support.  However, for over two decades, we have had an arm
gcc port that only emits 32-bit code.  If we rename that to aarch32,
we break two decades of backward compatibility.  Hence, for gcc, arm*
always means 32-bit.  If you mean 64-bit, then you have to use
aarch64.  Since aarch64 is not a simple extension of the armv7
architecture to 64-bits, but rather a new architecture with some
backward compatibility, we actually have two different compiler ports
for armv8 support, the old arm compiler that emits 32-bit code only
and the new aarch64 port that emits 64-bit code only.  Both are
capable of emitting ARMv8 code.  Only the arm port can emit ARMv7
code.

Similarly, the kernel uses "arm" and "arm64", because they were
unwilling to redefine what armvX means, and they were unwilling to
rename the arm port to aarch32.  Arm and arm64 are distinctly
different kernel ports.

> OK, thanks. So is neon-fp-armv8 an Aarch32 execution environment option?

I think "execution environment" is the wrong way to look at this.
There are two different compilers.  Arm and aarch64 are treated like
two separate architectures, each with its own separate compiler port.
It is possible to run an arm cross aarch64 compiler in the aarch32
execution environment, and it is possible to run an aarch64 cross arm
compiler in the aarch64 execution environment.  The important bit is
which compiler you are using, not your execution environment.

-mfpu=neon-fp-armv8 is an option accepted by the arm compiler.  it is
not accepted by the aarch64 compiler.  if you use the
-mfpu=neon-fp-armv8 option with the arm compiler, that tells it to
emit Neon and FP code using the armv8 architecture.

> So it looks like the course of action is to simply remove it from
> http://github.com/weidai11/cryptopp/blob/master/cryptest.sh#L874 . (It
> was added recently because of the ML recommendation).

It should be moved from the IS_ARM64 section to the IS_ARM32 section.
it is an arm option, not an aarch64 option.  The code as written will
only work if you are running 32-bit code on a 64-bit kernel, but that
should be OK.  You already have support for the 32-bit kernel in
checking for neon.  So if you have both the neon and the asimd checks,
then you are supporting code running on both 32-bit and 64-bit
kernels.  This assumes that no cross compiler will be used, as the
/proc/cpuinfo check won't work in that case.

> These ARM options are awful. I spent the better part of a day trying
> to untangle the option combinations to ensure we are getting good test
> coverage in a test script. I'd give my left arm device for a compiler
> that provides -march=native or -mfpu=native and gets it right.

Both the arm and aarch64 compilers support -march=native, but this
doesn't solve the arm FPU problem.  For arm, it is possible to run a
soft-float rootfs on a hard float part, so we can't tell whether to
emit FP code based on the CPU.  A reasonable default must be built
into the compiler, and if you want something different, you have to
request it on the command line.  For aarch64, FP and SIMD support is
required, so it is just a question of whether crc and/or crypto is
supported, and -march=native can handle that as there is no ABI change
when enabling/disabling them.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: -mfpu=neon-fp-armv8 and unrecognized command line option

[Jim Wilson]

On Wed, Jul 20, 2016 at 2:14 PM, Jeffrey Walton  wrote:
> I'm having trouble with ARMv8/Aarch64. One is an early Mustang server

ARMv8 implies 32-bit code (aarch32).  Aaarch64 implies 64-bit code.
These are two different compilers, with two different sets of command
line options.

> $ g++ -DDEBUG -g3 -O0 -mfpu=neon-fp-armv8 -fPIC -pipe -c cryptlib.cpp
> g++: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’
> GNUmakefile:753: recipe for target 'cryptlib.o' failed

-mfpu=neon-fp-armv8 is an arm (32-bit) compiler option.  The aarch64
(64-bit) compiler will not accept it.

Because FP and Neon support is optional in the 32-bit arm
architecture, there are compiler options to enable fp and/or neon
support.  Usually FP support is enabled by default for a linux distro,
but the neon support usually is not, and you can enable neon by using
this -mcpu=neon-fp-armv8 option if running 32-bit code on an ARMv8
architecture part.

Meanwhile, the aarch64 spec requires FP and ASIMD instruction support
in the linux ABI, so there are no options to enable them, they are on
by default.  If you really want to disable them, you can do so by
using a -march= option, e.g. -march=aarch64+fp+simd enables them, and
-march=aarch64+nofp+nosimd disables them.  However, if you disable fp
support, you will break the ABI, and your code may not compile or run,
so don't do that unless perhaps you have an embedded target, and have
your own OS build and your own ABI. or no code that uses FP  You can
also enable/.disable crc (crypto) support this way, but a better way
is to use a -mcpu= option, and let gcc figure out if the target has
crc instructions.

See the aarch64 compiler docs here
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Unable to locate libnl library while compiling the wpa supplicant with nl80211 and hostapd mode enable in toolchain gcc-linaro-4.9-2015.05-x86_64

[Jim Wilson]

On Tue, Jul 12, 2016 at 12:55 AM, Rohit Kamat  wrote:
> while I am cross compiling the  wpa supplicant with  toolchain
> gcc-linaro-4.9-2015.05-x86_64_arm-linux-gnueabihf for hostapd and nl80211
> mode enabled in menuconfig I am getting linker message ld:cannot find -lnl
> -3 (libnl) .
> I tried to locate the libnl libraries but they are not built in.
> could you please let me know how to enabled libnl in the toolchain.

The toolchain releases only contain toolchain libraries.  For all
other system libraries, you need to get them from the OS running on
the target system.

If you have a working target machine, then the normal process is to
create a sysroot by copying /usr/include, /usr/lib, and /lib from the
target system into a dir on the build machine, and then using the gcc
--sysroot= option to point at it when compiling.

If you don't havee a working target machine, but you are using a
standard OS release like debian or ubuntu, then you can use something
like lxc or schroot+debootstrap with qemu to create a target install
tree on your build machine, and then create the sysroot.

If you are using a linaro OS release, then you can probably just grab
a rootfs tarball, and then use that as your sysroot.

If you are building an OS from scratch, then you will have to build
libnl yourself.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Error: non-constant expression in ".if" statement

[Jim Wilson]

A few more comments...

The MAP_DATA support is emitting mapping symbols documented in the
AARCH64 ELF ABI.  Mapping symbols are emitted when switching from data
to instructions, or vice versa, inside a section.  However, mapping
symbols are just addresses.  There should be no need to emit implicit
alignment directives before padding symbols.  When switching between
data and instructions, it should be the responsibility of the
programmer or compiler to emit any necessary alignment directives.

The testcase is using e.g. ".align 11, 0".  This specifies that the
padding will be data bytes of 0, instead of perhaps a nop instruction.
Since we are explicitly emitting data into a text section, this forces
a switch when we emit the first instruction, which then forces an
implicit alignment directive.  if the code uses ".align 11" instead,
then the assembler will pad with nop instructions (or maybe zeros),
and there is no following switch from data mode to instruction mode.

The code to emit the implicit alignment directives is checking for a
.text section.  It should be checking for a section of any name that
contains code instead.  That eliminates unnecessary implicit alignment
directives emitted in non-text text sections, like in the example
which has a text section called .vectors.

I didn't try the first solution, as it isn't obvious why the
apparently unnecessary implicit alignment directives are being
emitted.  If this padding is necessary for some obscure reason, then
removing it would break something.

I did try solutions 2+3, and used together they allow the testcase to
work.  Patches attached.

Jim
3c3
<  .align 11, 0
---
>  .align 11
9c9
<  .align 7, 0
---
>  .align 7
diff --git a/gas/config/tc-aarch64.c b/gas/config/tc-aarch64.c
index 2163d53..85fa68a 100644
--- a/gas/config/tc-aarch64.c
+++ b/gas/config/tc-aarch64.c
@@ -1860,8 +1860,8 @@ s_aarch64_inst (int ignored ATTRIBUTE_UNUSED)
  MAP_DATA --> MAP_INSN transition.
  For other sections, this is not guaranteed, align it anyway.  */
   enum mstate mapstate = seg_info (now_seg)->tc_segment_info_data.mapstate;
-  if (!need_pass_2 && ((now_seg == text_section && mapstate == MAP_DATA)
-		   || now_seg != text_section))
+  if (!need_pass_2 && ((subseg_text_p (now_seg) && mapstate == MAP_DATA)
+		   || ! subseg_text_p (now_seg)))
 frag_align_code (2, 0);
 
 #ifdef OBJ_ELF
@@ -5710,8 +5710,8 @@ md_assemble (char *str)
MAP_DATA --> MAP_INSN transition.
For other sections, this is not guaranteed, align it anyway.  */
 enum mstate mapstate = seg_info (now_seg)->tc_segment_info_data.mapstate;
-if (!need_pass_2 && ((now_seg == text_section && mapstate == MAP_DATA)
-			 || now_seg != text_section))
+if (!need_pass_2 && ((subseg_text_p (now_seg) && mapstate == MAP_DATA)
+			 || ! subseg_text_p (now_seg)))
 	frag_align_code (2, 0);
 
   mapping_state (MAP_INSN);
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Error: non-constant expression in ".if" statement

[Jim Wilson]

On Tue, Jun 14, 2016 at 11:37 AM, Christophe Lyon
 wrote:
> On 14 June 2016 at 14:07, Jérôme Forissier  
> wrote:
>> Hi,
>>
>> I've stumbled across an assembler error message that I don't understand.
>>
>>  bl1/aarch64/bl1_exceptions.S: Assembler messages:
>>  bl1/aarch64/bl1_exceptions.S:53: Error: non-constant expression in
>> ".if" statement

I can reproduce with an FSF binutils.  Not obvious why it is failing though.

The assembler error comes because you are subtracting two addresses in
a .if, and one of more of those addresses is not a constant, because
the assembler could not calculate a fixed address on the first pass
through.  However, it isn't obvious why the assembler is failing to
calculate a fixed address, or why the aligns matter.  If the aligns
added a variable amount of in section padding, then that would prevent
the addresses from being constant.  But in this case, the aligns
should not be adding a variable amount of padding.  I'd have to spend
time debugging the assembler to figure out what is wrong here.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro GCC vs Valgrind

[Jim Wilson]

On Thu, Jun 9, 2016 at 2:22 PM, William Mills  wrote:
> When the optimizer is turned on valgrind complains about writes beyond
> the current stack pointer.  With the optimizer off, the problem report
> goes away.

> 000102f8 :
>102f8:   e351cmp r0, #1
>102fc:   da14ble 10354 
>10300:   e16d41f8strdr4, [sp, #-24]! ; 0xffe8
>   Complaint is here

This optimization is called shrink-wrapping.  It involves moving the
function prologue/epilogue inside an outer-most if statement, so that
we we can avoid allocating a stack frame when we don't need it.  It
can be disabled with -fno-shrink-wrap.  Perhaps valgrind has special
support to detect stack writes inside a prologue, and this support is
failing when a function is shrink wrapped because it can't identify
where the prologue is.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: toolchain fetch issues

[Jim Wilson]

On Wed, May 25, 2016 at 8:09 AM, Gujulan Elango, Hari Prasath (H.)
 wrote:
> I enabled the -v option of wget and I am able to see the download starts and
> fails randomly after progressing to some extent i.e. 10% or 27%. The
> connection is reset by peer and wget exits. I tried increasing the timeout
> option of wget as well.

This is some kind of networking or web server problem.  We only know
how to fix compiler problems here on the linaro-toolchain list.  I did
confirm that I can download the file OK, both via wget and via
chrome..  I noticed that the https support on releases.linaro.org is
not working, and I had to use http instead, but it isn't clear if that
is related to your problem.

Jim
___
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

Re: [ACTIVITY] 18-22 April 2016

[Jim Wilson]

On Sat, Apr 23, 2016 at 4:43 PM, Rob Savoye  wrote:
>   As a note, all the builders we use for binary releases run Trusty still. I
> haven't tried Jessie (should work fine),
> but I know that newer Mingw releases fail to compile GCC 5.x.

In the weekly status meeting, Maxim and Christophe looked at the Mingw
build jobs, and said that they are running on the Hetzners, which are
running Jessie.

I can confirm that an abe toolchain build on a Debian 8.4 Jessie
machine reproduces the Mingw failures reported in 2073 and 2174.  An
abe toolchain build on an Ubuntu 14.04LTS Trusty machine does not
reproduce the same failures.  Jessie has a 4.9.1 mingw cross
toolchain.  Trusty has a 4.8.2 mingw cross toolchain.  This could be a
bug in the gcc-4.9.1 release, or it could be a bug with the debian
jessie build of the mingw toolchain.  I haven't tried debugging the
jessie 4.9.1 mingw cross toolchain yet.

I can confirm that an abe toolchain build using -O -g for the gcc
build instead of -O2 -g produces a working toolchain that does not
fail for the 2073 and 2174 testcases.  The patch I used for this is
attached.  I haven't done any testing other than those testcases, so I
don't know if this is really a good toolchain or not.

FYI While looking at this, I ran into two abe build problems.
1) A mingw toolchain build with --disable update fails with a gdb
configure error saying that Python.h can't be found.
The problem here is that PYTHON_MINGW env var needs to be set in order
to find the python header files.  This is set in
checkout_infrastructure.  But checkout_infrastructure is not called
when --disable update, so the env var doesn't get set, and the build
fails.  The env var should be set somewhere else, or maybe set in both
the checkout and build functions.
2) A mingw toolchain rebuild after a gcc change fails with a
libsanitize error saying the scsi/scsi.h is missing.
The problem here is that the the linux kernel headers-install makefile
rule is run, which installs header files, and also removes header
files that the kernel doesn't think should be there.  scsi/scsi.h is
one of the files that is removed, which was installed by glibc.  The
glibc install is not redone, because glibc doesn't need to be rebuilt.
Then gcc gets rebuilt, and notices that the scsi/scsi.h file is
missing and fails.  This problem can presumably be worked around by
using "---build gcc" on the abe command line, if you know that only
gcc needs to be rebuilt.  I didn't reproduce this, or fully
investigate it, so it is possible that there is something else going
on here.

Jim
diff --git a/config/gcc.conf b/config/gcc.conf
index d0ee7c7..d4c4aac 100644
--- a/config/gcc.conf
+++ b/config/gcc.conf
@@ -67,6 +67,14 @@ if test x"${build}" != x"${target}"; then
# able to use the C library built with the first GCC build.
stage1_flags="--disable-libssp --disable-libquadmath --disable-threads --without-headers --with-newlib --disable-libmudflap --disable-bootstrap --disable-decimal-float --disable-libgomp --disable-libatomic --disable-libsanitizer --disable-plugins --disable-libitm MAKEINFO=echo --enable-languages=c --with-sysroot=${local_builds}/sysroot-${target} --disable-shared --with-glibc-version=2.18"
 
+# Add host specific flags.
+case ${host} in
+	*-mingw32)
+	# Debian jessie 8.4 mingw g++-4.9.1 generates bad code at -O2.  Miscompiles tree-ssa-ccp.c.  Override here.
+	default_configure_flags="${default_configure_flags} CFLAGS='-O -g' CXXFLAGS='-O -g'"
+	;;
+esac
+
# Add platform specific flags
 case ${target} in
 	armv8l-*linux-gnueabihf)
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

[Jim Wilson]

On Thu, Apr 7, 2016 at 7:46 PM, Pinski, Andrew
 wrote:
> Actually NTFS can be made to be case sensitive.

Good point.  I'd forgotten about that.  See
   https://cygwin.com/cygwin-ug-net/using-specialnames.html
about 1/3 of the way down it talks about turning off case insensitive
filenames with a registry change.  I don't know what this will do to
windows programs that might not be expecting case sensitive
filenames..

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

[Jim Wilson]

On Thu, Apr 7, 2016 at 2:43 AM, Gunnar Arndt  wrote:
> I've unzipped the Linaro gcc archive with WinRAR, and - what probably makes
> the difference - chosen NOT to overwrite duplicate files during unzipping.
> It works now for simple test programs, but I fear that there will be
> problems some time soon because of content not properly extracted.

I tried 7-zip.  In the extract window, there is a list of errors,
which reports that every symlink create failed.  It creates 0 size
files instead, which obviously won't work, and will give the error you
saw.  I tried WinRAR.  It also gave an error for every symlimk, but
produced a more useful error message that says I have to use
administrator mode.  It copies the symlink target into the symlink
instead, so I get a 8.9MB libstdc++.so file instead of the symlink I
was expecting.  This does work, but will waste some disk space.  Both
of these problems are fixed by running 7-zip or WinRAR as the
administrator.  I get correct symlinks in both cases.

The other problem with the duplicate files is due to a linux kernel
package called netfilter.  Linux has case insensitive filesystems, and
netfilter has some file names that differ only in case, e.g.
/usr/include/linux/netfilter_ipv6/ip6t_hl.h and ip6t_HL.h.  This is
unfriendly to windows which is case preserving, but not case
insensitive.  It looks like even cygwin is getting this wrong.  There
isn't much that can be done about this.  But this is only an issue if
you want to use the netfilter package, which is not common in
application programs.  If you do need to use netfilter, then you may
need to use a linux hosted cross compiler instead of a windows hosted
cross compiler.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

[Jim Wilson]

On Thu, Apr 7, 2016 at 2:43 AM, Gunnar Arndt  wrote:
> I've unzipped the Linaro gcc archive with WinRAR, and - what probably makes
> the difference - chosen NOT to overwrite duplicate files during unzipping.
> It works now for simple test programs, but I fear that there will be
> problems some time soon because of content not properly extracted.

Perhaps the issue is that the windows programs are confused by the
linux file names in the tar file.  Some of the file names have more
than one dot for instance.  I will have to try one of the programs you
mentioned later today.  If this is the case, then you might need to
use a linux tar to properly extract it, which means for instance the
cygwin tar, with winsymlinks set.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

[Jim Wilson]

On Wed, Apr 6, 2016 at 8:15 AM, Gunnar Arndt  wrote:

> embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:
> file format not recognized; treating as linker script
> c:/program files (x86)/gnu tools arm
> embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program
> files (x86)/gnu tools arm
> embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1:
> syntax error
> collect2.exe: error: ld returned 1 exit status

I get a slightly different error when I try this.  I get the file
format not recognized error, but then it quits instead of trying to
read it as a linker script.

The file in question is a symlink.  If you use a cygwin tar binary to
extract the tar.xz file on the windows machine, then cygwin by default
creates cygwin style symlinks, which can only be understood by cygwin
programs.  The toolchain we released is not a cygwin binary, so it
can't follow these symlinks, and you get the error.  I see two ways to
solve this problem.

1) In cygwin, you can do "export CYGWIN=winsymlinks" before extracting
the tar.xz file.  You will then get a windows short-cut instead of a
cygwin style symlink, and the toolchain will work.
https://cygwin.com/faq.html#faq.api.symlinks
The faq mentions different ls output, but I didn't see that.  I do see
a difference in file explorer.  The cygwin so symlink appears as type
"SO File", where as the windows short-cut appears as type "Shortcut".

2) Use a non-cygwin program to extract the package.  I don't know if
there is a non-cygwin tar available, but you could extract on a linux
machine, use zip to create a zip/pkzip archive, and then use a windows
unzip/pkzip program to extract it.  I didn't try this, but this should
in theory work.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Cross compilation issue

[Jim Wilson]

On Mon, Apr 4, 2016 at 8:18 PM, $rik@nth  wrote:
> There is no way to build static tool chain by using abe tool at all?

Maybe modify abe/lib/make.sh to add -static directly to LDFLAGS?

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Cross compilation issue

[Jim Wilson]

On Mon, Apr 4, 2016 at 11:30 AM, $rik@nth  wrote:
> I am issuing abe with `../abe.sh --set cflags="-static" --set
> ldflags="-pthread" --host arm-linux-gnueabi --target arm-linux-gnueabi
>   --build all`
> am i configuring something wrong here? Please correct me

That won't work without an arm-linux-gnueabi toolchain in the path.

When I try to build an arm-linux-gnueabi toolchain by dropping the
--host option, I get a glibc build failure
home/wilson/Linaro/tcwg/X-tmp/builds/x86_64-unknown-linux-gnu/arm-linux-gnueabi/glibc.git~release-2.21-master/config.h:4:3:
error: #error "glibc cannot be compiled without optimization"
--set cflags is overriding the default flags instead of adding to
them, so this isn't going to work.

If I try using --set cflags="-O2 -static", then I get an abe option parse error
ERROR (#612): check_directive (--stage requires a directive.  abe.sh
found the next -- switch.  See --usage for details.' )
This is trying to parse -static thinking it is the abe --stage option
because it accepts -sta* as an abbreviation.  Personally, I think all
of the abbreviations should be dropped as useless.  Anyways, it seems
it is ignoring the quotes when trying to parse the options.  It
appears that using the abe --set cflags option isn't useful, and you
won't be able to build a static toolchain this way.

I successfully built a cross by dropping the cflags and ldflags options.

I then tried to use it to build a canadian cross.  The build fails in
gdb, complaining that I don't have a libtermcap library which is true.
This is before it tried to build gcc, so I didn't get any gcc build.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Cross compilation issue

[Jim Wilson]

On Fri, Apr 1, 2016 at 7:10 AM, $rik@nth  wrote:
> I've read the Wiki page and start using abe tool to build cross
> compile for ARM on x86 build system. But i am getting below error.
> Also --set arch=arm argument is showing the arch is not found while 
> configuring.

Abe --set arch= translates into a gcc -march= option.  arm isn't a
valid argument for that in an arm toolchain.  A valid choice would be
armv7-a for instance.  But you shouldn't need an abe arch option
normally.  Only if you want a different -march= to be the default.

> /local2/mnt/tools/Linux-kernel/Linaro-GCC/abe/build/snapshots/gcc.git~linaro-gcc-5-branch/libgcc/libgcc2.c:59:1:
> error: __fixdfdi undeclared here (not in a function)
> /local2/mnt/tools/Linux-kernel/Linaro-GCC/abe/build/snapshots/gcc.git~linaro-gcc-5-branch/libgcc/libgcc2.c:59:1:
> error: __aeabi_d2lz defined both normally and as âaliasâ attribute
> /local2/mnt/tools/Linux-kernel/Linaro-GCC/abe/build/snapshots/gcc.git~linaro-gcc-5-branch/libgcc/libgcc2.c:59:3:
> warning: parameter names (without types) in function declaration
> [enabled by default]
> /local2/mnt/tools/Linux-kernel/Linaro-GCC/abe/build/snapshots/gcc.git~linaro-gcc-5-branch/libgcc/libgcc2.c:59:3:
> warning: parameter names (without types) in function declaration
> [enabled by default]
> make[2]: *** [_fixdfdi.o] Error 1

It isn't obvious what went wrong here.  Try looking at the
preprocessor output of the failing gcc command.  You didn't mention
the abe command used here.

It may take a little time to learn how to use abe to do a build.  Abe
tries to make builds easier, but it doesn't make them easy.

I don't know if abe can be used to do what you want.  The linaro
toolchain group doesn't do canadian cross builds except for windows
hosted builds, so we don't have any process to do what you want.
There is a linaro group that builds OS releases that contain native
gcc binaries.  I think that they use Open Embedded, but I've never
used Open Embedded, so I don't know how any of that works.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Cross compilation issue

[Jim Wilson]

On Sat, Apr 2, 2016 at 3:00 AM, $rik@nth  wrote:
> /home/hydlnxbld84/Srikanth/abe/build/snapshots/gcc.git~linaro-gcc-5-branch/gcc/real.h:79:76:
> error: size of array test_real_width is negative
>[sizeof (REAL_VALUE_TYPE) <= REAL_WIDTH * sizeof (HOST_WIDE_INT) ? 1 : -1];

I don't know offhand how one can get this error.  You'd have to look
at the preprocessor output here and try to figure out what wrong with
this calculation.  Maybe you accidentally used --build
x86_64-linux-gnu on a 32-bit machine?

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Question regarding the arm gcc 5.3 to build android

[Jim Wilson]

On Thu, Mar 31, 2016 at 5:04 PM, fengwei.yin  wrote:
> Remove the __thumb__ part?

If you remove the __thumb__ part, then you will get an assembler error.

palantir:2025$ arm-linux-gnueabi-as UnwindCurrent.s
UnwindCurrent.s: Assembler messages:
UnwindCurrent.s:1504: Error: PC not allowed in register list -- `stmia
r0,{r0-r15}'
palantir:2026$

This instruction is not a valid thumb instruction.  It is a valid arm
instruction, but deprecated.  The assembler gives an error because you
are in thumb mode.  Since you already have a __thumb__ version of the
macro, you can put a ".thumb" directive at the end of the asm, after
the orr instruction, to manually switch back into thumb mode.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Question regarding the arm gcc 5.3 to build android

[Jim Wilson]

On Wed, Mar 30, 2016 at 5:18 PM, yfw  wrote:
> /tmp/ccZ40ViQ.s:1752: Error: selected processor does not support ARM mode
> `cbnz r6,.L91'

Looking at gcc, I see that in thumb2 mode, for a conditional branch,
it will emit cbnz if the target is in range and it is using a thumb2
low register, otherwise it emits cmp/bne.  So this perhaps could be a
bug with the compiler calculating instruction sizes wrong, and hence
getting the range calculation from the branch to the target label
wrong.  We would need a reproducible testcase to investigate.  The
easiest way to do this if to add --save-temps to the g++ command, and
then send us the UnwindCurrent.ii file.  We also need the g++ command
line, but you already gave us that.  Otherwise, we have to figure out
how to build AOSP with gcc-5.3.  I'm not sure if anyone on the
toolchain team is doing that regularly.

There could also be something else going wrong here, e.g. the code
could have extended asms using cbnz which aren't valid in thumb2 mode,
the assembler could be somehow in thumb1 mode, etc, but these seem
less likely in this case.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Cross compilation issue

[Jim Wilson]

On Tue, Mar 29, 2016 at 8:03 AM, $rik@nth  wrote:
> gcc.o:(.rodata+0x5acc): undefined reference to
> `host_detect_local_cpu(int, char const**)'

This suggests a problem with the --host configure option.
host_detect_local_cpu is used only if __arm__ is defined, which means
you must be using an arm compiler to build gcc.  host_detect_local_cpu
comes from the driver-arm.c file, which is only added if the host is
arm*-*-freebsd* or arm*-*-linux*, and the target is arm*-*-*.  So it
appears that the --host configure option is wrong.

Sounds like you are trying to use an x86->arm cross compiler to build
a native arm gcc.  In this case, the configure command needs to have
--build=x86_64-pc-inux-gnu --host=arm-linux-gnueabi
--target=arm-linux-gnueabi for this to work.  Assuming you are
building on a 64-bit x86 linux pc of course.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Static arm-gcc

[Jim Wilson]

On Mon, Feb 22, 2016 at 6:11 AM, $rik@nth  wrote:
> Does linaro distributes arm-gcc as a pre-built static tool chain
> distribution? If yes, where can i download them from. Please point me some
> location from where i can download.

We (the toolchain group) don't build and release static toolchains.
And we don't build native arm/aarch64 toolchains.  We only build cross
compilers for linux and windows.  They can be found here
http://releases.linaro.org/components/toolchain/binaries/

Other parts of Linaro build and release linux distros, and you can
find native compilers built from our compiler sources in those linux
distros.  These compilers aren't static either, and they presumably
only work as part of that distro.

If you want a static native compiler for some other distro, you would
have to build it from source, possibly as a cross build if you
currently don't have any native compiler.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [fido][meta-linaro-toolchain] arm-none-eabi-4.8-2014.04

[Jim Wilson]

On Fri, Feb 19, 2016 at 1:38 PM, Xi Zhou Zhou  wrote:
> I download the pre-built toolchain for one of our armv6 board.
> https://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2014.04_linux.tar.xz

This is the embedded toolchain, for systems not running linux.

> After plug it into Yocto as an external toolchain, it failed to install it
> correctly.

Yocto is linux, so there is a contradiction here.  It isn't clear why
you are trying to do this, as this is not expected to work.

> ../meta-linaro/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb,
> do_install
> | DEBUG: Executing shell function do_install
> | cp: cannot stat
> `/opt/gcc-linaro-arm-none-eabi-4.8-2014.04_linux/arm-none-eabi/libc/lib/*':
> No such file or directory

Yocto is looking for the linux toolchain sysroot, but this isn't a
linux toolchain, so there is no sysroot.

If Yocto is supposed to work with embedded toolchains, then you need
to fix the yocto scripts to make the toolchain sysroot optional.

Or if you are really trying to download the linux toolchain, then you
should instead grab

https://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.xz

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: armhf toolchain with glibc 2.13

[Jim Wilson]

On Sat, Jan 30, 2016 at 5:35 AM, Aaron R  wrote:
> My ARM target runs glibc 2.13 and I am having a hard time finding a
> linaro toolchain for it. It seems like all the ones I have found ship with
> glibc 2.15 (even old ones).

If you link statically, most code compiled against a newer glibc is
likely to work.  One potential problem is that a newer glibc might
call a newer kernel syscall entry point, which may not exist in your
kernel if you have an old one, but this is likely to be a rare
problem.  And of course anything that requires dynamic linking won't
work if statically linked, but this is usually only a problem for
large and complex programs.

> Where can I find the binaries for a linux toolchain that targets armhf
> with glibc 2.13?

It looks like we have some very old releases that used eglibc-2.13
http://releases.linaro.org/archive/12.03/components/toolchain/binaries/
This was only tested on 4 year old linux versions which are obsolete,
and is so old that we don't support it anymore.  This being one of the
very first binary toolchain releases from Linaro, I have no idea how
well it works.

You may be better off if you build one yourself. If you can copy files
off of your target, then create a target sysroot containing /lib,
/usr/lib, and /usr/include.  Put a copy of this target sysroot on your
cross compiler host.  Then configure binutils and gcc using
--with-sysroot= pointing at the path to the target sysroot.  You only
need to build binutils and gcc, and you need to configure, build, and
install binutils before doing the same for gcc.  You can get the
target gcc configure options by using gcc -v on the target, then
adjust the options so that they make sense on the cross compiler build
system, e.g. don't use --prefix=/usr as you should not install the
cross compiler into /usr on the build system.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro 4.9 toolchain has issues with allyesconfig

[Jim Wilson]

On Thu, Jan 28, 2016 at 2:26 PM, Renato Golin  wrote:
> We have this bug in LLVM:
> https://llvm.org/bugs/show_bug.cgi?id=23969
> Which deals with the problems of mcount messing up the prologue, and
> it seems to affect both kernel and chromium.

This is an unrelated problem.

> I was delaying the decision to move to __gnu_mcount_nc on ARM
> unconditionally, but if GCC requires the -mlong-calls option, then I
> think we could make it work very easily.

GCC does not require -mlong-calls.

This is a specific problem related to the kernel allyesconfig option
which enables everything, resulting in a kernel so large, with ld -r
combined text sections so large, that we get out-of-range calls that
linker relaxation can't fix.  I was suggesting -mlong-calls as a
workaround, except that it turns out that -mlong-calls -pg doesn't
work, because we always emit a short-call to mcount, even when
-mlong-calls is specified.  That is a minor bug in the gcc ARM port.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro 4.9 toolchain has issues with allyesconfig

[Jim Wilson]

On Wed, Jan 27, 2016 at 9:30 AM, Richard Earnshaw
 wrote:
> Long calls would probably solve the problem, but would likely be
> horribly expensive in performance.

An allyesconfig is presumably only to verify that you haven't
accidentally broken any build config with a patch, so performance
should not be a concern.

> The best solution would be to have an option to prevent ld -r from
> merging like-named sections (instead just aggregating multiple sections
> with similar names into one object file).  This is possible in ELF.

Another way to do this is to make an archive file instead of using ld
-r, and then use --whole-archive  --no-whole-archive.
That would avoid the need for linker changes.

While it might be possible to make an ELF file with multiple sections
with the same name, that would likely confuse lots of tools, and
require cascading changes, which could get ugly.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: GCC's ABI 5

[Jim Wilson]

On Wed, Jan 20, 2016 at 3:49 AM, Yvan Roux  wrote:
>> I don't know how much distros were involved in the original design.
>> Did they request the changes? Or was that an internal change? How do
>> you guys get to decide when to break the world?

It appears that changes to the C++ standard forced the ABI change, and
the addition of abi_tag was an attempt to support both C++ standard
versions in parallel during the transition period.

I see a patch from Jason Merrill here
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg00475.html
which says this was discussed at the GNU Cauldron in Prague in 2012.
I was there, but I 'm not a C++ guy,  so I don't recall this
discussion.  The GNU Cauldron is well attended by various distro
contributors (Debian/Ubuntu, Red Hat, SuSE at least), so there should
have been reasonable coverage at the time.  I don't know if any clang
representatives were present.

It appears that a complaint from doko started this mess.  I see two
parallel threads complaining about ABI incompatibilities between C++98
and C++11 right before the GNU Cauldron, one of which is from doko.
https://gcc.gnu.org/ml/gcc/2012-06/msg00201.html
https://gcc.gnu.org/ml/gcc/2012-06/msg00202.html

Then in July, I see a third thread started by Jason Merrill that seems
to have the first suggestion of using an attribute to change mangling.
https://gcc.gnu.org/ml/gcc/2012-07/msg00031.html

Then during the Cauldron, a summary of the C++ ABI BOF which I likely
did not attend
https://gcc.gnu.org/ml/gcc/2012-07/msg00098.html
See in particular Ian's reply which has a lot more details about the
proposed GNU solution.  The initial message mentions HP and Sun
solutions to this problem, but doesn't talk much about the GNU
solution.  This talk would have been attended by Ubuntu, Red Hat, and
SuSE folks at least, so there should have been some agreement from the
distros before we implemented a solution.

Then eventually came Jason's initial implementation patch in November.

While the feature was added a while ago, it wasn't until C++11 was
made the default that it became visible to end users, and that
happened with GCC 5.  Maybe there wasn't enough discussion with the
clang guys before the switch was made from C++98 to C++11.  Us gcc
guys aren't used to having to discuss things with other compiler
developers.  We are good about talking to distro vendors, but we keep
forgetting about clang.

I found an old wiki page that talks about ABI changes between C++98 and C++11.
   https://gcc.gnu.org/wiki/Cxx11AbiCompatibility

I doubt that there is any formal specification of any of this stuff
anywhere.  The attribute abi_tag is documented in the gcc manual.

https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
You perhaps care more about how libstdc++ uses it, which isn't in the
gcc manual.  I do see two mentions in the libstdc++ docs
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html

Most of the discussion of this feature probably occurred on the
libstdc++ mailing list which I don't read.  I have limited knowledge
of C++, and basically no knowledge of the gcc C++ front end, so I
can't comment on the C++ technical matters here.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: gcc-linaro-5.1 vs gcc-linaro-4.8

[Jim Wilson]

On Tue, Jan 5, 2016 at 4:19 PM, Xiaofeng Ren  wrote:
> Hello Jim,
> Appreciate for your comments.
> I will try to manually apply that patch on my side and try it.
> BTW, may I know which released Linaro gcc version include that patch?   Maybe 
> I can download it and try it quickly.
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00025.html

It was backported to our gcc-5 branch on Nov 24 by Yvan.  This is
after the latest release 2015-11 was made.  The patch is in the
December snapshot, but I think that is a source only release.
http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.3-2015.12/
You would have to build your own toolchain from that, perhaps by using abe.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: gcc-linaro-5.1 vs gcc-linaro-4.8

[Jim Wilson]

On Tue, Jan 5, 2016 at 6:53 PM, Rob Savoye  wrote:
>   Is it in the 2015.11-1 release ?

I found gcc-linaro-5.2-2015.11-1-rc1.tar.xz on the snapshot site.  I
don't see it in this release either.  This seems to have identical gcc
sources to the 2015-11 release, other than a patch to change the
linaro version number.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: gcc-linaro-5.1 vs gcc-linaro-4.8

[Jim Wilson]

On Tue, Jan 5, 2016 at 5:52 AM, Xiaofeng Ren  wrote:
>> Gcc-5.1:
>>   40110c:   3dc00c6cldr q12, [x3,#48]

>> Gcc-4.8:
>>   40135c:   4cdf78afld1 {v15.4s}, [x5], #16

The ld1 and ldr instructions are effectively equivalent, they are both
loading 16-byte values into fp/simd registers.

I see a difference in the scheduling though.  The gcc-4.8 output has a
series of shift/add/store instructions while the gcc-5.1 output has a
series of shift instructions followed by a series of store
instructions.  The gcc-5.1 output will serialize the code as these are
simd shifts which can only execute one at a time, and stores can only
execute one at a time.  I see that gcc-4.8 has no cortex-a53 pipeline
description, so we appear to be getting good code by accident.  The
gcc-5.1 has a cortex a53 scheduler, but it doesn't handle simd
instructions, so it isn't scheduling them correctly.  I see that there
was a change added in November
   https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00025.html
that adds a new a53 pipeline description, and this one does handle
simd instructions.  With current sources, I see some shifts,
alternating shifts and stores, and then the last of the stores.  This
should give better performance than the gcc-5.1 code.  I haven't tried
testing it on hardware.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Linaro-binutils release git tags

[Jim Wilson]

On Wed, Dec 16, 2015 at 9:12 PM, Virendra Kumar Pathak
 wrote:
> As per release notes, linaro_binutils-2_25-2015_01-2_release should be
> present at http://git.linaro.org/toolchain/binutils-gdb.git.
> But I am not able to see any "linaro_binutils" tags on
> https://git.linaro.org/toolchain/binutils-gdb.git/tags.

Perhaps the person who added the tags forgot to do a "git push
--tags".  I've made that mistake myself a few times.

it looks like the January 2015 release was made via some ad-hoc
process.  It came after the last release using the crosstools scripts,
and before the first release using ABE, so it may not have been a very
rigorous release process, and may not be reproducible.  I joined in
February, so I wasn't here at the time, and don't know exactly what
happened.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: why ld.so in arm-linux-gnueabihf- toolchains search so many paths ?

[Jim Wilson]

On Wed, Dec 2, 2015 at 12:07 AM, Barry Song <21cn...@gmail.com> wrote:
> i am wondering whether ld.so will check the capbility of ARM to decide
> which version should be used.

I believe the way this works is that the kernel uses the auxiliary
vector to pass an AT_HWCAP entry to programs.  AT_HWCAP has hardware
capability info.  ld.so then checks the AT_HWCAP info, and only
searches in matching dirs.  See for instance
https://wiki.linaro.org/Resources/HowTo/DeterminingCPUFeatures

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Bug: Linaro ABE abe.sh doesn't allow timeout > 10 seconds

[Jim Wilson]

On Wed, Dec 2, 2015 at 1:32 PM, Christopher Roberts
 wrote:
> abe.sh in the ABE framework accepts a parameter to set the wget timeout when
> it fetches snapshots (default 10s); however that parameter has an upper
> threshold of 10 seconds (condition at line 996 only sets timeout to
> specified value if < 11). Is this intentional? It seems like it would make
> more sense to give it a floor instead of a ceiling or perhaps not limit the
> range of potential values at all.

I have no idea why it works the way it does.  It looks like it was
inherited from an earlier tool that I don't know anything about.  But
I'd suggest filing a bug at bugs.linaro.org if you care, as bug
reports are tracked, and probably more likely to get a useful answer
than a question to this list.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Runtime inlining

[Jim Wilson]

On Fri, Nov 6, 2015 at 6:48 AM, Zoltan Kiss  wrote:
> I've checked link time optimization (-flto), but it only helps with static
> linking. Is there any way to keep the ODP application and platform
> implementation binaries in separate files while having the performance
> benefit of inlining?

I haven't been able to think of a good way to do this, and apparently
no one else has either.

There is a not so good way to do it.  You could distribute relocatable
link (i.e. ld -r) output instead of executables and shared libraries,
and then do the final LTO compile and link at run-time.  This just
creates a new set of problems though.  There would be a long delay for
the LTO compile and link before you start routing packets which would
be inconvenient.  It would be better to do the LTO compile and link
just once and reuse the binary, but then you have the problem of where
do you put the binary and how do you give it proper owner and group
permissions.  There may also be issues with using ld -r with LTO.  You
probably don't want this mess.

Otherwise, you need some kind of JIT or rewritable code scheme to redo
compiler optimizations at run-time, and we don't have that technology,
at least not with gcc.  I don't know if LLVM has any useful feature
here.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [lng-odp] Runtime inlining

[Jim Wilson]

On Mon, Nov 9, 2015 at 2:39 PM, Bill Fischofer
 wrote:
> The IO Visor project appears to be doing something like this with LLVM and
> JIT constructs to dynamically insert code into the kernel in a
> platform-independent manner. Perhaps we can leverage that technology?

GCC has some experimental JIT support, but I think it would be a lot
of work to use it, and I don't know how stable it is.
https://gcc.gnu.org/wiki/JIT
The LLVM support is probably more advanced.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: GCC performance questions

[Jim Wilson]

On Wed, Nov 4, 2015 at 7:07 AM, Gunnar von Boehn
 wrote:
> Looking at the created code of GCC on ARMv8, we noticed some areas where
> there is room for performance improvements.
> I assume that these items might already be noticed by you guys.

There is a known problem that the current register allocator doesn't
handle partial overlap very well.  Both aarch64 and aarch32 use the
same register set for FP and SIMD/neon, which results in lots of
partial overlaps, which can confuse the register allocator into using
unnecessary temporaries.  Otherwise, I don't think that we have any
major problems, other than the fact that vectorization is a hard
problem to solve, and we do have lots of examples showing non-optimal
code generation in certain cases.

> 1)  We noticed that when writing typical DGEMM like code, GCC includes
> unnecessary DUP instruction

This could be the known register allocation problem.  It is hard to
say more without a testcase.

> 2)  GCC seems unwilling to use LDP loads

There is support for generating LDP/STP, but since this usually
involves combining unrelated data, it is done in a peephole pass and
may not be triggering as often as we like, as the peephole
optimization only works well if you get lucky register allocation and
instruction scheduling that creates peephole optimization
opportunities.  Can't say more without a testcase.

> 3)  For optimal FPU performance on some A57 its needed to interleave
> instruction working on ODD and EVEN registers
> GCC seem not properly support this. Here sometimes  100% performance
> increase could be reached by different instruction interleaving.

A patch was added to GCC 6 for this.  It looks like it has been
backported into the Linaro gcc-5.x sources.  From git log on the
Linaro gcc-5.x tree:

commit 9c9ff2bc6885aa07d55ecef8248c08a8e14ff9b6
Author: Christophe Lyon 
Date:   Mon Oct 5 15:17:57 2015 +0200

gcc/
Backport from trunk r222512.
2015-04-28  Thomas Preud'homme  

PR target/63503
* config.gcc: Add cortex-a57-fma-steering.o to extra_objs for
aarch64-*-*.
* config/aarch64/t-aarch64: Add a rule for cortex-a57-fma-steering.o.
* config/aarch64/aarch64.h (AARCH64_FL_USE_FMA_STEERING_PASS): Define.
(AARCH64_TUNE_FMA_STEERING): Likewise.
* config/aarch64/aarch64-cores.def: Set
AARCH64_FL_USE_FMA_STEERING_PASS for cores with dynamic steering of
FMUL/FMADD instructions.
* config/aarch64/aarch64.c (aarch64_register_fma_steering): Declare.
(aarch64_override_options): Include cortex-a57-fma-steering.h.  Call
aarch64_register_fma_steering () if AARCH64_TUNE_FMA_STEERING is true.
* config/aarch64/cortex-a57-fma-steering.h: New file.
* config/aarch64/cortex-a57-fma-steering.c: Likewise.

Change-Id: I92e0e8d06fc5212e8856d6d5f9c7c6b83a737ca8

There are a number of related changes after this one.  I don't know
how well this works as I haven't tried using it.

> 4)   Some work loops highly benefit of interleaving of FPU instructinons
> and loads.
> GCC seems to likes to re-arrange the code so that most or all loads are put
> on top of the loop.
> This can reduce the performance of a well written workloop significantly.

This isn't an ARM specific problem, and within the ARM family, it is
target dependent, as it depends on how the instruction scheduler hooks
have been written for the target you are optimizing for.  I know for
some of the cortex parts, there was an effort to report fewer
load/store pipes than exist, so that gcc would not schedule all loads
at the start of a loop.  I don't know how effective it is though.

> Please tell me what the next recommended step will be now.
> Are all these items known already, or shall I provide code examples  to
> further explain them?

You can try filing bug reports into the FSF bugzilla at
http://gcc.gnu.org/bugzilla or the Linaro bugzilla at
http://bugs.linaro.org.  Bugs filed into the FSF bugzilla will get
better visibility, as all ARM gcc developers will see them.  The
problems you are reporting are mostly hard problems that may not be
fixed for a while, and these kinds of problems are probably better
reported into the FSF bugzilla.  Issues specific to Linaro should of
course go into the Linaro bugzilla.  You can try giving us testcases
here, but if it isn't something we can fix in a few minutes, then it
is better if it goes into bugzilla.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Question about the Linaro toolchain version

[Jim Wilson]

On Mon, Oct 19, 2015 at 7:23 PM, Luo Zhenhua  wrote:
> The default gcc version of Yocto 2.0(Jethro) is 5.2.0, the gcc version in
> meta-linaro is gcc-4.9.4, may I know if gcc-linaro-4.9.4 will be used for
> Yocto 2.0 release?  when will the linaro gcc be upgraded to gcc-5.x?

I don't think that we have any say over Yocto.  We just make releases,
and they decide which ones to use.

The previous binary release 15.06 was the last one to include
gcc-4.8.x support.  The next binary release will be the first one to
include gcc-5.x support, though I haven't seen it come out yet, I
think it is expected soon.  We have already made source snapshots of
gcc-5.x available.  There were some delays with the binary releases
because of instabilities with our build farm.  Those problems have
been fixed, though we might end up shifting the schedule a bit because
of the delays.

> BTW, can someone please help point out where the Linaro toolchain roadmap
> can be got?

There was a roadmap talk at the HKG15 Connect
http://connect.linaro.org/resource/hkg15/hkg15-203-tcwg-2015-roadmap-review/

I don't know if there is a more recent one.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Building for armv6/ARM1136J-S using ABE

[Jim Wilson]

On Fri, Sep 11, 2015 at 10:54 AM, Bill Davis  wrote:
> I’ve tried probably a dozen different ABE build command lines with various
> combinations of cpu/arch/tune on the latest  tree and on the 2014.09 release
> and am unable to build for the armv6/1136J-S.

FYI there is a wiki page that talks about ABE
   https://wiki.linaro.org/ABE
In particular, it mentions the "temporary" workaround needed to get
files to download.

My experience is that ABE tends to work fine if you are using the same
way as tcwg, and it can behave poorly if you are trying to use it a
different way.  tcwg doesn't build for armv6.

> /tmp/ccTT8UgL.s:492: Error: lo register required -- `add
> pc,r3,#(0x0fc0-0x0fff)'
> /tmp/ccTT8UgL.s:490: Error: invalid immediate: -61441 is out of range

This is a glibc problem building csu/libc-start.c.  It calls some
atomic functions, and we end up in
sysdeps/unix/sysv/linux/arm/bits/atomic.h.  At the bottom, it has a
definition for __arm_assisted_compare_and_exchange_val_32_acq.  There
is one for thumb2, and one for arm, but no definition for thumb1.

abe by default builds the compiler --with-mode=thumb.  You are
building for an armv6 part that does not have thumb2 support, so your
compiler is emitting thumb1 code by default, which won't work.  I
don't think it is a good idea to try to build everything as thumb1
code.  I would suggest disabling --with-mode=thumb in the gcc
configure options.

I see that Charles Baylis has responded while I was writing this up,
and explains that you have to edit abe/config/gcc.conf to git rid of
the --with-mode=thumb option.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: help: cortex-a7 u-boot hang at pcie with gcc-linaro-4.9

[Jim Wilson]

On Tue, Sep 1, 2015 at 12:48 AM, Liu Ting  wrote:
> When trying to use gcc-linaro-4.9 to build u-boot for ls1021atwr (ARM
> Cortex-A7 MPCore compliant with ARMv7-A architecture), we face issue. U-boot
> hangs at PCI-E.
>
> After tracing the code, the issue is located at the line “*val =
> readl(addr);”.
>
> u-boot/drivers/pci/pcie_layerscape.c: ls_pcie_read_config():
>

> After Bisecting, we tracked down a gcc commit:
> https://git.linaro.org/toolchain/gcc.git/commitdiff/e4f9e85e8152379aef373772b22075539920ffa2?hp=da278625cc33cbbc893cc50c2ac32fca31053ee8
> 2015-01-23  Jakub Jelinek  
> PR rtl-optimization/63637
> PR rtl-optimization/60663
> * cse.c (merge_equiv_classes): Set new_elt->cost to MAX_COST
> ...

It is hard to look at a compiler issue when I can't reproduce the
problem.  You gave good info about the compiler, but you didn't point
at u-boot sources.  i tried
  git clone  http://git.linaro.org/boot/u-boot-linaro-stable.git
but there is no pcie_layerscape.c file.

The problem fixed by the patch can be seen here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63637
A description of the patch can be found in the submission email here:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00894.html
There are testcases in the patch that show what it does.

The patch allows the compiler to optimize away redundant extended asm
statements via common subexpression elimination (CSE), when the asm
statements aren't volatile, don't have multiple outputs, and don't
have memory clobbers.

If this is breaking your code, then it appears that you are missing a
volatile declaration or extended asm memory clobber somewhere.  I
don't have the code to look at, so I can't suggest what might be wrong
with the code.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: abe - compiling cross aarch64 toolchain using local directory

[Jim Wilson]

On Wed, Aug 19, 2015 at 8:32 AM, Virendra Kumar Pathak
kumarvir.pat...@gmail.com wrote:
 ../abe/abe.sh --target aarch64-linux-gnu --build all --release
 20150819 --tarbin
 gcc=file:///home/vpathak/arm/toolchain/build/snapshots/gcc-2015.11-5.tar.bz2

 But I get following error:
 ERROR (#146): get_URL (not supported for .tar.* files.)

Yes, that is documented as working, but doesn't actually work.  I
believe that there is already a bug report for this at
bugs.linaro.org.

What you can do instead is just create your own local git repository,
and then point the gcc= option at your git tree.  You should name your
git tree gcc.git otherwise you will have trouble with abe.  If you
have your own local gcc.git tree, and you are using a shared local
snapshot tree, and you are doing builds with both the linaro gcc.git
and your local gcc.git, then you can run into problems, because you
can't have two different gcc.git trees in the shared local snapshot
tree.  If you want two gcc.git trees, then you have to do it without
sharing of the local snapshot tree.  Or alternatively, it is possible
to hack up abe so that a non gcc.git tree name can work.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: ABE - bug in copy_gcc_libs_to_sysroot() while building native toolchain for aarch64

[Jim Wilson]

On Sun, Jul 26, 2015 at 11:36 PM, Virendra Kumar Pathak
kumarvir.pat...@gmail.com wrote:
 In copy_gcc_libs_to_sysroot()  - which copy libgcc.a to sysroot, current
 implementation try to find the absolute path of libgcc.a as below :
 libgcc=`${local_builds}/destdir/${host}/bin/${target}-gcc
 -print-file-name=${libgcc}`

The easy solution is to change ${host} to ${build}, here and immediately above.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: binutils - question on decoding decision tree for aarch64

[Jim Wilson]

On Sat, Jul 25, 2015 at 6:19 AM, Virendra Kumar Pathak
kumarvir.pat...@gmail.com wrote:
 1. Please help me in knowing what I am doing wrong here ? What else I should
 do to add a new instruction in binutils ?

I don't know offhand, but see below.

 2. I also saw some printf in opcodes/aarch64-gen.c which I guess create
 decoding tree (initialize_decoder_tree()). How to print them ? I made debug
 =1 but still print is not coming.

It looks like it prints debug info to stdout, so the debugging info is
in the output files like aarch64-asm-2.c.

 3. There are some auto-generated files like aarch64-asm-2.c,
 aarch64-dis-2.c. How to re-generate them ?

Use --enable-maintainer-mode when running configure.  This enables
makefiles rules for the auto-generated sources.  These are normally
disabled by default to make it easier to build the source tree.  With
this enabled, you may need extra utilities installed for a build to
work, especially if you haven't been careful about preserving file
timestamps.  This enables rules to generate flex/bison output files,
and autoconf/automake output files, and files like aarch64-asm-2.c.

If you didn't do this before modifying aarch64-tbl.h, then this may be
why your changes aren't working.  With --enable-maintainer-mode,
changing aarcht64-tbl.h will automatically rebuild aarch64-gen on the
next make, and that will then automatically be rerun to regenerate
files like aarch64-asm-2.c.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: abe: cross native toolchain compilation for aarch64-linux-gnu

[Jim Wilson]

On Fri, Jul 17, 2015 at 3:47 PM, strongq stro...@codeaurora.org wrote:
 Now I’m running into new problem. I’m trying to enable “--with-python
 option” for building gdb.

 For the native Linux version, I just need to install Python-dev package. But
 for cross compiling the windows version, I don’t know which Linux package is
 for mingw. It cannot find the ‘Python.h’.

Ubuntu only provides a basic mingw cross compiler.  If you want
python, you would have to build that yourself.

 So I’m just wondering is it possible to build the win32 gdb executable, with
 the python option enabled?

It should be possible, but it might be easier if you build it on a win32 system.

 Another big question, is that possible to use ABE under Cygwin and has
 anybody tried?

I don't know.  But abe is primarily useful for building linux crosses,
which is a complex process involving multiple glibc and gcc builds to
resolve interdependencies between them.  Your target is
aarch64-none-elf, which is much simpler to build cross.  It would not
be hard to do this build directly without abe.  First you build and
install binutils.  Then you drop the newlib sources into gcc, and
build and install gcc with the same --prefix used when configuring
binutils.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: abe: cross native toolchain compilation for aarch64-linux-gnu

[Jim Wilson]

On Thu, Jul 16, 2015 at 12:40 PM, strongq stro...@codeaurora.org wrote:
 The config.log is under 
 _build/builds/i686-w64-mingw32/aarch64-none-elf/binutils-gdb.git~linaro_binutils-2_24-branch-binutils/libiberty
 My understanding that it is for building the binutils.

Yes.  So I was looking at the wrong config.log file.  But even in this
one, I see that the test for strerror was run.
configure:5956: checking for library containing strerror
configure:5990: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -D__USE_MINGW_ACCES\
S  -static-libstdc++ -static-libgcc  -Wl,--stack,12582912 conftest.c  5
configure:5990: $? = 0

However, I don't have a linaro_binutils-2_24-branch-binutils tree.  I
have a linaro_binutils-2_25-branch-binutils tree.  I mentioned before,
I am doing builds on a Ubuntu 14.04LTS (x64_64) system, using the
master branch of abe.  I don't think that you have mentioned the host
OS or the abe branch.  You must be using a different abe version.
Perhaps there is a bug in the abe version that you have.  Or maybe if
you are running a different version of linux, maybe there is an
interaction problem between abe and that OS that is causing the build
failure.  Without full info about your setup, I can't reproduce your
problems, and hence can't easily help you.

 So with default host setting, it will build the binutils last. But why with 
 i686-w64-mingw32 host, it will build this binutils right after building 
 infrastructure? Is it expected or something wrong with my config?

binutils always gets built before gcc.  However, it is possible that
it was installed last, and that make install caused some files to be
created inside the binutils dir, such as doc files not created by make
all but required by make install.  Or maybe binutils was installed
first, but was the only dir that created files in the build tree at
make install time.  Either of these could explain why the binutils dir
has the newest timestamp at the end.

 I read about Canadian Cross from Wikipedia: 
 https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross

You could also try looking at
http://crosstool-ng.org
It is another set of scripts like abe to do builds.

 But still not fully understand the magic here with ABE. I think the 
 x86_64-unknown-linux-gnu folder is for building the toolchain for ARM target, 
 but runs on Linux PC. But how this could be used for generate toolchain for 
 running on Windows? Seems i686-w64-mingw32-gcc is not involved during the 
 build, isn't it?

The basic process for building a canadian cross requires 3 steps.
1) Build a cross compiler to the host (build=x86_64-linux
target=i686-w64-mingw32)
2) Build a cross compiler for the target (build=x86_64-linux
target=aarch64-linux)
3) Build a canadian cross compiler (build=x86_64-linux
host=i686-w64-mingw32 target=aarch64-linux)

In the third step, we use the compiler from step 1 to create all of
the binaries that will run on the host machine.  Also, in the third
step, we use the compiler from step 2 to create all of the libraries
that will run on the target machine.

Abe takes a short cut here, and uses the Ubuntu mingw32 package to
supply the compiler for step 1.  So we only need to do the last two
steps.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: abe: cross native toolchain compilation for aarch64-linux-gnu

[Jim Wilson]

On Tue, Jul 14, 2015 at 8:10 PM, strongq stro...@codeaurora.org wrote:
 Thanks Wilson for your reply. I was very busy and finally got some time on 
 this.
 First, I followed your suggestion, built a 'Hello world' program with 
 i686-w64-mingw32-gcc. The generated executable runs well on Windows PC.

 So I back to check the config.log file.
 As I mentioned early, I will build with default host option first. And build 
 with host as i686-w64-mingw32 again.

 With the default host option, the config.log shows:
 configure:5322: result: yes
 configure:5946: checking for library containing strerror
 configure:5980: gcc -o conftest -g -O2  -static-libstdc++ -static-libgcc  
 conftest.c  5

 With host option set for mingw32, the config.log shows:
 configure:5322: result: yes
 configure:5946: checking for library containing strerror
 configure:5978: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

Which exact config.log file is this?  There are a lot of them.  You
mentioned libiberty.  There should be two libiberty dirs in the gcc
build tree for build and host, and one in the binutils tree and one in
the gdb tree.  I'm guessing this is the host one in the gcc build
tree, 
builds/i686-w64-mingw32/aarch64-none-elf/gcc.git~linaro-gcc-5-branch-stage2/libiberty/config.log.

In my copy of the file, I see
configure:6080: checking for library containing strerror
configure:6114: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -D__USE_MINGW_ACCES\
S  -static-libstdc++ -static-libgcc -Wl,--stack,12582912 conftest.c  5
configure:6114: $? = 0

This compiler is able to link, so we are able to do link tests here.
GCC_NO_EXECUTABLES should not be set.

But maybe you are looking at a different config.log file?

 Based on the last several line, since I'm doing cross compiling, $gcc_no_link 
 should be set to yes. So I'm very confused about this. Frankly, I'm not very 
 familiar with autoconf and those scripts. I just want some simple instruction 
 to do the build for windows. We need the python option for gdb enabled. I 
 also noticed the 4.9.2014.11 Linaro binary, the file size of 
 arm-none-eabi-gdb.exe is about 30M Bytes, and with xml disabled which leads 
 to problem for using it with certain target. The previous 4.8.2014.9 release 
 is less than 5M and it works perfect.

abe is not a fool proof tool, and neither are any of the alternatives
like crosstool-NG.  Learning how to build cross takes a little time.
It was fairly simple for me to do the build, using the master branch
of abe I just needed to do two abe builds and it worked, but then I
have used abe before and already have an environment set up for it to
work.  It isn't obvious why it didn't work for you.  Another
alternative is to try doing builds natively on the windows machine.
That may or may not be easier.

Offhand I don't know about the gdb issue.  I know that we changed from
crosstool-ng to abe sometime, late last year I think, so maybe the two
gdb's are configured differently.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [activity] 6 - 10 july 2015

[Jim Wilson]

On Mon, Jul 13, 2015 at 12:17 AM, Prathamesh Kulkarni
prathamesh.kulka...@linaro.org wrote:
 - for -O2 temps introduced by peephole2 due to define_peephole2
 pattern in thumb2.md:1540
 http://pastebin.com/3rEF8Te4
 So this intentionally transforms rtx from
 zeroextractsi_compare0_scratch to rtx from shiftsi3_compare0_scratch.
 Why is it beneficial to do this transform ?

I used svn blame to find the revision where the pattern was added,
then svn log to get the changelog entry and date from that revision,
and searching the gcc-patches mailing list on that date I found this
https://gcc.gnu.org/ml/gcc-patches/2010-06/msg02518.html
It doesn't explain much, but refers to an earlier change, so I did a
google search for thumb2_tlobits_cbranch to find when this pattern was
added, and that gives me
https://gcc.gnu.org/ml/gcc-patches/2010-05/msg3.html
which refers to bug 42879 which has the explanation we want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42879

tst is a 32-bit thumb2 instruction, but lsls is a 16-bit instruction,
so it is a minor size optimization.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: abe: cross native toolchain compilation for aarch64-linux-gnu

[Jim Wilson]

On Fri, Jul 10, 2015 at 8:49 AM, strongq stro...@codeaurora.org wrote:
 First build this: ../abe/abe.sh --target aarch64-none-elf –build all
 Then do 2nd round build: ../abe/abe.sh –host i686-w64-mingw32 --target
 aarch64-none-elf –build all

I just tried this on an Ubuntu 14.04 LTS system using the master
branch of abe, and the build completed successfully.  Not obvious why
it didn't work for you.

I did manage to find a minor abe bug, but it didn't stop the build
from completing.

 However, I’m getting config error while it building libiberty:
 configure:5946: checking for library containing strerror
 Configure:5978: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
 My understanding is that the linker cannot find glibc or eglibc.

Neither mingw32 nor aarch64-elf use glibc/eglibc.  They both use
newlib.  The issue here is that you can't try linking until after you
have built gcc and installed its startfiles and libraries.  However,
gcc needs to do target feature tests as part of its configuration.
The solution is that in the gcc configure scripts we try to avoid
feature tests that require linking for cross compilers, and if we
can't avoid it, then we hard code in the correct answer for known
libraries like newlib and glibc.

Anyways, it isn't obvious from the error what is wrong.  You need to
look at the config.log file in the directory that failed to configure.
This will contain info about the configure tests that were run in this
dir, and the last one will be the one that failed.  You then need to
look at this test to see why it failed.  In this case, the real error
may be earlier, where GCC_NO_EXECUTABLES was set.

If this was the host (i686-w64-mingw32) libiberty that failed, then
maybe there is a problem with your i686-w64-mingw32-gcc binary.  Can
you build a hello world program with it?

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: new gas feature: section name substitution sequence

[Jim Wilson]

On Mon, Jun 8, 2015 at 11:36 AM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
 Unless I'm missing something obvious, I can't find any section where all
 options are documented together. There is the Invoking section but it
 contains very few options and only the most generic ones.  All the
 others are documented here and there in the manual with a reference to
 them added to the index as I did.

I only saw one documentation hunk in your patch, and that was in the
middle of the .section pseudo-op description.  An option should be
mentioned in the overview section, and then for target independent
options a longer description in the invoking section if necessary.
Target dependent options get documented in the target dependent parts
of the manual.  Putting longer descriptions elsewhere may be
appropriate, and your docs in the .section psuedo-op section seemed
OK, but not also without a mention in the overview which I didn't see.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: new gas feature: section name substitution sequence

[Jim Wilson]

On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
 I created a patch on top of upstream binutils for a feature I need which
 should be universally useful as well. Now I have 3 questions for you:

 1) Does it look sane enough?

You added the option docs into the .section docs.  It is certainly OK
to talk about it here, but there is also a list of all options in the
docs, and the new option needs to be documented here also.  One could
perhaps refer to the other.  Otherwise, the patch looks OK, but I have
little experience using macros, so I'm not sure if there might be a
better way to do this.  I'm also not sure how the other binutils
maintainers would feel about the design.  It would have to be
discussed on the binutils mailing list.

 2) If so, could you integrate it in the Linaro release?

The normal toolchain process is that patches get added to our releases
only if they are already upstream.  Our releases are FSF releases plus
patches backported from mainline, with no local changes except when
absolutely unavoidable.  I think that we'd rather delay a release so
we can submit a patch upstream first than make a release on time with
an extra non-FSF patch.  So this needs to get into FSF binutils first,
and then we need a business reason to backport it, e.g. a member
explicitly asks us to backport it, or it fixes a bug that a member
reported, or is needed by a major open source project.

 3) Would you be willing to promote it upstream?

We would need a business reason to promote it upstream, as above.
Otherwise it would be a personal decision, and I don't know if there
are any active binutils developers here that might be interested.  It
is probably best to just go through the normal binutils patch
submission process.  They tend to be pretty open to patches, and tend
to accept anything that looks like it might be useful, unless there is
already another way to do this making your patch redundant, or if your
patch conflicts with some existing feature, etc.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: question on bfd - arch mach

[Jim Wilson]

On Wed, May 27, 2015 at 1:21 AM, Virendra Kumar Pathak
kumarvir.pat...@gmail.com wrote:
 1. In the struct bfd_arch_info {...} (in bfd/bfd-in2.h) there are two fields
 'enum bfd_architecture arch' and 'unsigned long mach'.
 I went trough the binutils porting guide (by mr.swami.re...@nsc.com) which
 says 'arch' is for architecture  'mach' is for machine value.
 At present in the bfd/bfd-in2.h :- arch = bfd_arch_aarch64 and mach =
 bfd_mach_aarch64 or bfd_mach_aarch64_ilp32.
 But what these fields really means ? What is the difference between 'arch'
 and 'mach'?

arch is for different incompatible architectures, e.g. sparc versus
mips versus arm.  mach is for different incompatible machines within
an architecture.  So for arm we have for instance bfd_mach_arm_2 for
armv2 and bfd_mach_arm_5T for armv5t, etc.  These fields have little
meaning outside what the rest of the binutils code gives to them, so
the author of a port can use them however he sees fit, and sometimes
different ports use them slightly differently.  Practical
considerations will sometimes force particular choices, to get a
working linux system.

 Lets say instruction set architecture is ARMv8 (also known as aarch64 for 64
 bit- if I am not wrong). Then we have specific implementation of this like
 cortex53, cortex57, Cavium ThunderX etc. With respect to this what will be
 the value of arch = ? and mach = ?

All of the announced aarch64 parts implement the same instruction set
(more or less), so they all use the same mach value, bfd_mach_aarch64.

 2. In the include/opcode/arm.h the 'arm_feature_set' is defined as a
 structure where as in include/opcode/aarch64.h 'aarch64_feature_set' is
 defined as unsigned long. Is there any specific reason for this? Why
 structure definition was not followed in aarch64 ?
 typedef struct
 {
 unsigned long core;
 unsigned long coproc;
 } arm_feature_set;

 typedef unsigned long aarch64_feature_set;

Ports are free to implement this as they see fit.  Often different
people will do it slightly differently.  There is no requirement to do
it exactly the same way as some other port.  So no requirement that
aarch64 do anything exactly the same as how the arm port did it.

On the practical side, arm is an old architecture, which has many
variants, and has a definite need to express different feature sets.
Whereas aarch64 is new, and as yet does not have any specific need for
different feature sets, since all of the announced parts implement
mostly the same feature sets.  So aarch64 has a simple definition as
it doesn't need anything complicated here.  And arm has a complicated
definition, as this was necessary to get correct behaviour from the
arm port.

 3. Also I see that in the case of arm, 'mach' values are derived from cpu
 extension value specified in that 'arm_feature_set' structure.
For example.
 if (ARM_CPU_HAS_FEATURE (cpu_variant, arm_cext_iwmmxt2))
 mach = bfd_mach_arm_iWMMXt2;
Whereas in aarch64 mach is derived based on API type (64 or 32). Any
 reason for this ?
mach = ilp32_p ? bfd_mach_aarch64_ilp32 : bfd_mach_aarch64;

These are effectively working the same way.  The only difference is
that there are many arm variants, but only one aarch64 variant, which
is why there are many bfd_mach_arm* codes and only one
bfd_mach_aarch64* code.

As for the ILP32 ABI, it is incompatible with the default LP64 ABI,
and traditionally ILP32 and LP64 use different ELF formats (ELF32
versus ELF64), so it is convenient to give the ILP32 ABI its own
machine code so that we can use the machine code to select the ELF
format.  This is also done for x86, where 32-bit, 64-bit, and x32 ABI
are 3 different machine codes.

There is a practical consideration here that if you are using mach
codes for ABIs, and have x ABIs, and are using mach codes for
implementations, and have y implementations, then you would need x*y
mach codes to represent every combination of ABIs and implementation,
which would quickly get impractical.  So for instance in the x86 port,
they only have a few mach codes for implementations, even though there
are dozens of variants of the x86 architecture.  A mach code is not
the only way to express a different implementation.  It is an
implementer's choice whether to use a mach code or some other
mechanism.

In the arm port for instance, the mach codes only go up to armv5te.
Beyond that, the toolchain started using a .ARM.attribute section to
describe machine info, and we stopped adding machine codes for each
arm architecture variant.  The .ARM.attribute section can contain a
lot more info than can be represented in the mach field.  This is
probably why there is no bfd_mach_arm_6 and bfd_mach_arm_7, as they
weren't needed once we started using .ARM.attribute sections.  A
similar mechanism will likely be added to the aarch64 port once that
architecture has enough variants that it would benefit from having an
attribute section.

Jim
___
linaro-toolchain 

Re: writing a new Machine Description file (e.g cortex-a57.md) in gcc

[Jim Wilson]

On Thu, May 7, 2015 at 4:24 AM, Virendra Kumar Pathak
kumarvir.pat...@gmail.com wrote:
 I am new to gcc development. I am trying to write a new md file describing
 pipeline information for a processor.
 Please suggest some good reference document for understanding machine
 description file.

There is some documentation for pipeline descriptions in the gcc manual.

https://gcc.gnu.org/onlinedocs/gccint/Processor-pipeline-description.html#Processor-pipeline-description

Or if you want the entire docs for the md file, you can find them here
https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc
This is in the gcc/doc/md.texi file if you want to read the
documentation source.

 For first integer pipeline following is defined - (define_cpu_unit
 cortex_a53_slot0 cortex_a53)

 Is name cortex_a53_slot0 is a keyword or it is any general string?
 Is there any convention in choosing names for cpu units?
 If ‘cortex_a53_slot0’ a general string, how assembler knows it is first
 integer pipeline?

It is a general string, that needs to be unique.  Putting the
processor name in there helps make it unique across different
processors.  The rest of it is just something that makes sense for the
target, preferably something that maps to the processor documentation.

The compiler does not know that it is the first integer pipeline.  All
it knows is that some following define_insn_reservation patterns use
it. These define_insn_reservation patterns will map the
cortex_a53_slot0 cpu unit to the set of instructions that can execute
on the first integer pipeline.

 How these *.md files are used? When they are compiled and how they are used?

There are various genX programs that read the md file and generate a
insn-X.c file to perform actions based on info in the md file.  For
instance genrecog creates the insn-recog.c file, which is for
recognizing RTL patterns that map to valid instructions on the target.
genemit creates the insn-emit.c file which emits the assembly code for
an RTL insn.  Etc.

 How to verify an md file for a processor is written correctly or not? How to
 test it?

It is generally not possible to verify that a md file is correctly
written.  All you can do is test it, and try to exercise as much of it
as possible.  Testing it means compiling code, and trying various
different option combinations when compiling to exercise more of the
code.  The more code you compile the better test it is.  Bootstrapping
the compiler is a good correctness test.  Building an entire linux
distro is a better correctness test.  Running the gcc regression
testsuite is a good correctness test.  You will also want to do
performance testing.  Anything you can time will work.  Running
standard benchmarks like SPEC is a good test.  You can time how long
it takes to bootstrap gcc for instance, or maybe just pick one large
gcc source file, and time how long it takes to compile that file.

 What other design consideration must be kept in mind while writing a new md
 file?

If you want to contribute it to the FSF, then you will need to worry
about copyright assignments.  The FSF will only accept code if they
own the copyright, and it is free of any patent claims.  This can be
one of the hardest parts of contributing to GCC if you work at a
company that hasn't dealt with FSF copyright assignment paperwork
before.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: writing a new Machine Description file (e.g cortex-a57.md) in gcc

[Jim Wilson]

On Thu, May 7, 2015 at 10:56 AM, Jim Wilson jim.wil...@linaro.org wrote:
 There are various genX programs that read the md file and generate a
 insn-X.c file to perform actions based on info in the md file.  For
 instance genrecog creates the insn-recog.c file, which is for
 recognizing RTL patterns that map to valid instructions on the target.
 genemit creates the insn-emit.c file which emits the assembly code for
 an RTL insn.  Etc.

I got this wrong.   genoutput and insn-output.c are for the assembly
code.  genemit and insn-emit.c are for emitting the initial RTL.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Build u-boot using Linaro toolchain

[Jim Wilson]

On Tue, Apr 21, 2015 at 12:35 PM, Joel (Xi Zhou) Zhou
joel.z...@broadcom.com wrote:
 The u-boot built with gcc-linaro-arm-none-eabi-4.9-2014.09_linux can boot on
 the development board. This toolchain was pre-built toolchain from Linaro,
 built with crosstool-NG. The version is gcc version 4.9.2 20140904
 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC
 4.9-2014.09)

 With the same u-boot source, the binary built with the Linaro gcc 4.9
 2015.04 hang on the same board. The 2nd toolchain was compiled locally on
 RHEL6, built with ABE tool. We build it locally to avoid “GLIBC_2.14 not
 found” issue on the pre-built toolchain. The version is gcc version 4.9.3
 20150413 (prerelease) (Linaro GCC 2015.04)

The older toolchain is built with crosstool-NG.  The newer one is
built with ABE.  There are likely some subtle differences in behaviour
between them, and this might be causing the problem.  This would not
be a problem normally, but low level code like bootloaders are more
sensitive to these kinds of things.  Or it could be a latent bug in
the new release.

Since you have one compiler that works and one that doesn't, I would
suggest that you try mixing them to isolate the problem.  Compile
uboot with the old release and link with the new release to see if
that works.  Compile uboot with the new release and link with the old
release to see if that works.  That should isolate the problem to
either gcc or binutils.  If it is the new gcc that is broken, then try
reducing compiler optimization levels to see if that helps.  If it
does help, then you can do bisection across the source tree to try to
find one file that causes a failure at high optimization levels but
works at low optimization levels.  You can then debug from there.  If
it is the new binutils that is the problem, then you can try using
objdump and/or readelf to look for subtle differences in the output
that might be causing problems.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Issue building busybox using aarch64-linux-gnu 2014.11

[Jim Wilson]

On Wed, Apr 15, 2015 at 9:51 AM, Kevin Petit kevin.pe...@arm.com wrote:

 It seems none of the built-in library search paths (gcc –print-search-dirs)
 allow to find crt[1i].o. They seem to be expected in a multiarch location
 but aren’t (libc/usr/lib64). We’re working around this with a symlink. Is
 this a bug? Have you seen similar issues?

I downloaded a toolchain from this page.
https://www.linaro.org/downloads/

It works fine for a simple example.  I don't see anything in the
option list that would cause a problem.  Busybox could perhaps be
setting environment variables to change compiler behaviour, that can
cause problems, but it is rare that people set gcc environment
variables.  That isn't obvious from the bug report.  I haven't built
busybox in a long time, so I don't know if it is doing anything
unusual offhand.

You can debug this yourself a bit by adding a -v option to see the
linker option that gcc is running.  This should contain explicit paths
to the crt1.o and crti.o files.  You can check to see if the paths are
correct and the files exist.  If there environment variables set, they
should be in the -v output.

You can also add -Wl,--verbose to get verbose info from the linker.
This will show you the linker built-in paths, and what files the
linker is trying to open.  For my simple testcase I see

attempt to open
/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crt1.o
succeeded
/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crt1.o
attempt to open
/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crti.o
succeeded
/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/../lib64/crti.o

In the gcc --print-search-dirs output, at the end, I see

/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/lib/:/home/wilson/Downloads/gcc-linaro-4.9-2014.11-x86_64_aarch64-linux-gnu/bin/../libc/usr/lib/

These are the paths used to find the 64-bit libraries, which are just
../lib64 from the 32-bit libraries.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: -O2 faster than -O3

[Jim Wilson]

On Thu, Apr 2, 2015 at 3:19 AM, Edward Nevill edward.nev...@linaro.org wrote:
 Looking at the disassembly I see it is using FP registers to hold
 integer values. The following is a small extract.

-O3 turns on -finline-functions, which causes a lot of code expansion.
That, combined with the fact that we end up with a call in the middle
of a loop, and most values have lifetimes that cross the call, means
that it runs out of registers, and needs to spill.  The compiler is
then choosing to use FP registers for spills instead of
storing/loading to/from the stack.  I'm not seeing the same behaviour
from the FSF GCC mainline, nor from the linaro-4.9 branch.  These are
both spilling to stack instead of FP registers.

This appears to be FSF GCC Bug 61915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
which was fixed in November and back ported to our linaro branch last month.

Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain