== Progress ==
TCWG-680 Some analysis on what non-compiler support would be required
for an llvm based EBC (UEFI) toolchain.
TCWG-612 ARM TLS support in LLD: Initial support and tests for
standard model upstreamed. There is still some work to be done for
corner cases where LLD's relaxations will cause assertion failures.
Static linking also needs some work as the TLS module index needs to
be written into the GOT without a dynamic relocation. I have a
prototype fix that needs cleaning up and tests written.
Did some experiments with static linking and TLS to work out what I'll
need to look at next. Discovered GNU ifunc support when static linking
is not working.
Did some thinking about what would be needed to support C++ exceptions
in LLD for ARM. This is probably the next major chunk of work as
supporting exceptions is needed when static linking against the C
library startup code.
== Plans ==
Plans for next 4 weeks:
On Sabbatical back on the 22nd August. Will probably have limited
access to email if there is anything urgent.
Peter
== Progress ==
* ARM: Different ABI functions based on optimization level [TCWG-669]
- Patch committed upstream
* PR26038 - inline assembly assertion building ARM linux kernel
[TCWG-590] [2/10]
- Patch committed upstream
* PR24234 - [AArch64] error in backend: fixup value out of range
[TCWG-681] [5/10]
- Started investigating
* AArch64 Bugzilla scrub [2/10]
- Closed a couple of bugs that couldn't be reproduced
- Added a few interesting bugs to TCWG-678
* Minor updates to the helper scripts [TCWG-630, TCWG-649] [1/10]
== Plan ==
* PR24234 - [AArch64] error in backend: fixup value out of range [TCWG-681]
- Looks like a tough one :)
Hi Everyone,
I'm looking at the features of a BeagleBone Black. Its /proc/cpuinfo is below.
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.
My question is, what GCC ARM option is used when we encounter the
neon, vfpv3 and vfpd32 flags?
Thanks in advance.
**********
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
BogoMIPS : 996.14
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part : 0xc08
CPU revision : 2
Hardware : Generic AM33XX (Flattened Device Tree)
Revision : 0000
Serial : 0000000000000000
Hi Everyone,
I'm having trouble with ARMv8/Aarch64. One is an early Mustang server
board (without CRC or Crypto), and the other is a LeMaker HiKey (with
CRC and Crypto). Both run Linaro:
apm-mustang: $ cat /proc/cpuinfo
Features : fp asimd evtstrm
And:
hikey: $ cat /proc/cpuinfo
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
According to the GCC folks, we can get better code generation with
-mfpu=neon-fp-armv8
(http://gcc.gnu.org/ml/gcc-help/2016-05/msg00058.html and
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html). However, it
results in:
$ 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
It looks like -mfpu=neon-fp-armv8 is a GCC 4.9 feature
(http://gcc.gnu.org/gcc-4.9/changes.html), and Linaro supplies GCC
4.9.2:
$ g++ --version
g++ (Debian/Linaro 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
I'm wonder why the option is not being consumed by GCC. Are there any
ideas what I should be doing differently?
Thanks in advance.
Jeff
* On holiday [6/20]
# Progress #
* TCWG-655, Workaround ARM linux kernel ptrace bug. [2/20]
After the discussion, patch is posted. Pedro is on holiday, so the
patch is pending there for review.
* TCWG-518, ARM range stepping patches. [3/20]
The last "to-be-approved" patch is posted. Pending for review.
* TCWG-333, Thumb mode function pointer assignment in GDB. [2/20]
Working on a patch to handle both ARM/thumb and PPC64.
* TCWG-179, TLS variables can't be resolved in aarch64 GDB. [4/20]
GCC doesn't produce DW_AT_location
for TLS variable, because target hook TARGET_ASM_OUTPUT_DWARF_DTPREL
isn't defined for AArch64. Thanks to Jiong and Szabolcs's help, pick
up knowledge on TLS descriptor and TLS modes quickly. Still need to
figure out how to describe the location of TLS variable in debug info
if they are unknown in compilation/link time.
* Fix gdb.gdb/*.exp and gdb.mi/mi-reverse.exp test fails. [1/20]
* Upstreams patch review. [1/20]
* LAS16, sort out the invitation letter for US visa. [1/20]
# Plan #
* TCWG-333, TCWG-518, TCWG-655 and TCWG-179
* US visa application.
--
Yao
The Linaro Toolchain Working Group (TCWG) is pleased to announce the
2016.07 snapshot of Linaro GCC 6 source packages.
Linaro GCC 6 monthly snapshot[1] is based on FSF GCC 6.1+svn238201 and
includes performance improvements and bug fixes backported from
mainline GCC. This snapshot contents will be part of the 2016.08
stable[2] quarterly release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.1-2016.07/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 6.1+svn238201
Subscribe to the important Linaro mailing lists and join our IRC
channels to stay on top of Linaro development.
** Linaro Toolchain Development "mailing list":
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@
* Bug reports should be filed in bugzilla against GCC product:
http://bugs.linaro.org/enter_bug.cgi?product=GCC
* Interested in commercial support? inquire at "Linaro support":
mailto:support@linaro.org
[1]. Source package snapshots are defined when the compiler is only
put through unit-testing and full validation is not performed.
[2]. Stable source package releases are defined as releases where the
full Linaro Toolchain validation plan is executed.
Hi Linaro Members,
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.
Thanks
Best Regards --
Best Regards,
Rohit Kamat
CallSend SMSCall from mobileAdd to SkypeYou'll need Skype CreditFree via Skype
== Progress ==
* ARM: Do not test for CPUs, use SubtargetFeatures [TCWG-623]
- Committed all 3 patches upstream
* ARM: Different ABI functions based on optimization level [TCWG-669]
- Patch in upstream review, had to rework it a bit
* PR26038 - inline assembly assertion building ARM linux kernel [TCWG-590]
- Patch in upstream review
* Refactor SelectionDAGBuilder::visitInlineAsm [TCWG-643]
- In progress (trying to break it up into a few helper functions)
* Misc
- TCWG Sprint prep (slides etc)
== Plan ==
* TCWG Sprint
* Commit TCWG-669 and address any review comments on TCWG-590
== Progress ==
TCWG-653 ARM/Thumb interworking veneers
Committed upstream after several review rounds and at least one set of
build bot failures in systems/compilers we don't have set up.
TCWG-612 ARM TLS support in LLD
Have an implementation and most of the tests. Should be ok to upstream
next week.
Found that llvm-mc doesn't implement .word sym(tlsldo). Have a simple
fix that I'll need to upstream before I can test local-dynamic.
== Plan ==
11 - 15th July TCWG Sprint
== Absences ==
25th July - 20th August Sabbatical
