All,
During Connect the suggestion was made that each working group should have
its own IRC Channel for discussions and topics relating to the group in
particular (as opposed to #linaro which is 'generic' Linaro conversations).
Therefore I have just set up #linaro-tcwg on Freenode for the Toolchain
Working Group.
This channel is public and open to anyone who wants to talk with the TCWG
group about anything toolchain related.
Thanks,
Matt
--
Matthew Gretton-Dann
Toolchain Working Group, Linaro
Hi Linaro Toolchain Group,
I am going through the binutils code base specific to arm & aarch64. Please
give some insight on below questions.
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.Reddy(a)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'?
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 = ?
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;
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;
Thanks in advance.
--
with regards,
Virendra Kumar Pathak
== Progress ==
TCWG-775 NEON error messages (2/10)
. wrote new patch for Aarch64
. tried to test it, but GCC testsuite stopped working on my laptop
(random failures with "test for errors, tests randomly being marked
UNSUPPORTED)
Bank Holiday [2/10]
Bug #1599 [1/10]
. reproduced bug on Linaro GCC 4.9
, bisected both the cause and the trunk fix
Misc [5/10]
. attempted to diagnose GCC testsuite problems. Seems to be related to
kernel version somehow.
. Erratum workaround stuff (bug 1550, bug 1596)
== Plans ==
Find working kernel for laptop
Cleanup/submit patch for TCWG-775
Create JIRA cards following vectorization study (TCWG-735)
Bank holiday on Monday. [2/10]
# Issue #
No. Ubuntu is successfully installed on my chromebook.
# Progress #
* Linaro GDB [4/10]
** TCWG-517, GDB AAarch64 record/replay. Done.
Patches are committed upstream. Fix one build failure caused
these patches.
** TCWG-805, aarch64 native debugging multi-arch support.
*** Switch to PTRACE_GETREGSET and PTRACE_SETREGSET. Patches are posted
upstreams.
*** Get ubuntun 14.02 running on chrombook successfully.
** Give my input on GDB kernel awareness too.
* FSF GDB [3/10]
** PR 18392, review the fix and understand the code about tail call
unwinding.
** Approve and commit some tiny patches.
* Misc [1/10]
** Prepare for incoming France travel.
** Book flight and hotel for GNU Tools Cauldron.
Next week:
* TCWG-805, aarch64 native debugging multi-arch support.
--
Yao
== Progress ==
* Bank Holiday (2/10)
* Maintenance (CARD-1833 6/10)
- Finished all FIXMEs in LLVM and Clang
- Working on ASM warnings
* Background (2/10)
- Code review, meetings, discussions, etc.
- Updated arm-bots.html to account for build num, commit range
== Plan ==
* Continue working on ASM warnings
* Move a few left-overs in ARMAsmParser to use ARMTargetParser
If time allows...
* Check the ADD -> SUB change in the assembler
* Try to get the test-suite running on a CMake buildbot
Background
* Check the progress of some Android bugs
* 1 day off
* Neon intrinsics tests (4/10)
- submitted last set for review
* Misc (4/10)
- meetings, conf-calls, emails, ...
- checks for our new GCC mirror
== Next ==
* Neon intrinsics tests: work on vget_lane test.
* linaro-gcc-5.1-2015.06 release:
- start working on backports
* TCWG-619 (2/10)
- "branch out of range" error disappears by disabling sibling call optimization
- using gold results in internal error at arm.cc:4192
- using ld.bfd results in tons of same errors message during LINK
chrome - "thumb2 branch out of range"
- building with "-dp" option shows the error comes for function calls,
generated from pattern call_value_symbol.
* PR49551 (2/10)
- Bootstrapped on x86, tested on x86 and arm.
- added test-case.
* Misc (6/10)
- Exams
== Next Week ==
- Submit patch to PR49551 upstream
- Continue investigating "branch out of range" error.
- Rebase and submit cfgloop.h flattening patch upstream.
== Progress ==
* Upstream GCC (8/10)
- vector cost (TCWG-779)
- benchmarking complete and analysed
- Committed after full testing (bootstrap and regression testing)
- Started working on widening pass based on review comments (TCWG-555)
- Completed re-factoring with the new ideas
- ran into many ICEs with the patch and making progress
* Misc (2/10)
- Looked at http://ctuning.org/wiki/index.php?title=CTools:MilepostGCC
again
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
== Progress ==
* Releases (CARD-1431 1/10)
- Final ARM/AArch64 3.6.1
* Automation Framework (CARD-1378 1/10)
- More meetings with Lab about infrastructure
* Maintenance (CARD-1833 5/10)
- Working on FIXMEs to TargetParser
* Buildbots (CARD-1823 1/10)
- Bisecting self-hosting failure on thumbv7a
* Background (2/10)
- Code review, meetings, discussions, etc.
- More stride vectorizer reviews (D9368)
- Setting up boards for developers
== Plan ==
* Finish the parser FIXMEs, get on with ASM warnings
* Check some Android bugs and see if I can reduce their numbers
* Probably a bit more infrastructure discussions
