Hi Linaro Toolchain Group,
Is there any tool for checking coding style of the patches submitted to the
Linaro Toolchain ?
In other word is there any equivalent of Linux checkpatch.pl in Linaro
Toolchain (GCC, Binutils etc) ?
If yes, please let me know.
If not, then in general how people check the coding style of the patches
they submit to Linaro Toolchain (GCC, Binutils etc).
I assume manual inspection (line by line) may be very tedious thing to do.
Thanks.
--
with regards,
Virendra Kumar Pathak
== Progress ==
* Upstream GCC (8/10)
- TCWG-486 - Optimize Constant Uses in Loops.
- Jeff reviewed it and asked for some minor changes
- Rebased and redid full testing and posted it
- TCWG-555 - Complete re-write of widening pass based on review comments
- Getting ready to post for review
* Misc (2/10)
- Reading TACT User Manual
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
== This week ==
* Bug 539 - .LTHUNK symbols are surviving (2/10)
- Built Qt 4.8 using 4.9 and 4.9 toolchain and verified fix
identified by Jim Wilson
- Plan to close as fixed
* Bug 535 - static cast from float to int not working on ARM hardfp (2/10)
- Investigation
* TCWG-140 - Transform end of loop conditions to min_expr (1/10)
- Investigation into blueprint and patch
* TCWG-146 - Detect smin/umin idiom (2/10)
- After investigation no patch deemed necessary for aarch64
* Misc (1/10)
- Conference calls
* US Holiday - Memorial Day, May 25th (2/10)
== Next week ==
- Submit Aarch32 patch for TCWG-146 upstream
- TCWG-140 investigation
== This week ==
* TCWG-619 (4/10)
- Chromium builds with LTO single-partition with gold by changing
arm_is_long_call_p() to always return true, thereby disabling short
calls.
- Fails to build with ld.bfd for single partiition with the following error:
obj/third_party/webrtc/base/rtc_base.ipaddress.o: In function
`rtc::IPAddress::IPAddress(unsigned int)':
ipaddress.cc:(.text._ZN3rtc9IPAddressC2Ej[_ZN3rtc9IPAddressC5Ej]+0x28):
undefined reference to `vtable for rtc::IPAddress'
- gas debug for "Thumb2 branch out of range" in config/tc-arm.c:
Fails in md_apply_fix at following condition:
if ((value & ~0x3fffff) && ((value & ~0x3fffff) != ~0x3fffff))
{
if (!(ARM_CPU_HAS_FEATURE (cpu_variant, arm_arch_t2)))
as_bad_where (fixP->fx_file, fixP->fx_line, BAD_RANGE);
else if ((value & ~0x1ffffff)
&& ((value & ~0x1ffffff) != ~0x1ffffff))
as_bad_where (fixP->fx_file, fixP->fx_line,
_("Thumb2 branch out of range"));
}
The condition became true for value == fffffda
Backtrace: http://pastebin.com/QZqbwNCy
Options passed to as: -march=armv7-a -march=armv7-a -mfloat-abi=hard
-mfloat-abi=hard -mfpu=neon -mfpu=neon -meabi=5
- Disabling the above condition results in:
arm-linux-gnueabihf-g++: internal compiler error: Killed (program lto1)
* PR49551 (2/10)
- Modified patch and retested on x86 and arm.
- Submitted patch upstream for review.
* Misc (4/10)
- Exams ended on Monday.
- College Annual day.
== Next Week ==
- Work towards getting the patch approved.
- Continue investigating "Thumb2 branch out of range" error.
- Begin with TCWG-777.
- Submit cfgloop.h flattening patch upstream.
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
# Issues #
* Don't have arm board to run native gdb testsuite (my pandaboard is
too slow to run native tests). Get a chromebook, but takes a lot
of time installing ubuntu on it. Network still doesn't work, don't
know how much time are still needed to fix networking issues.
# Progress #
* Linaro GDB
** TCWG-517, GDB AAarch64 record/replay. [3/10]
These bits are finally posted upstream. The review looks good.
** TCWG-805, aarch64 native debugging multi-arch support. [4/10]
*** Switch to PTRACE_GETREGSET and PTRACE_SETREGSET. Patches are done,
but takes much time to set up GDB native testing env, as linaro
tcwglab is still unreachable.
Install ubuntun 14.02 on chrombook. Done, but network driver
doesn't work.
** Give my input on GDB kernel awareness.
** Tweak pandaboard for native gdb testing. Done.
** AArch64 debugging on different ELs, a meeting is scheduled
in the sprint but I ask more details before that meeting.
* FSF GDB [1/10]
** Review a patch about arm abi detection for ELFOSABI_GNU. Approve it.
** Review a patch about compile feature in GDB.
* Misc [2/10]
** Go to London for France Visa application on Monday and get visa on
Thu.
# Plan #
* TCWG-517, GDB AAarch64 record/replay.
Address review comments and push them in.
* TCWG-805, aarch64 native debugging multi-arch support.
Set up chromebook and test my patches on it.
--
Yao
Holiday Thursday afternoon and Friday [3/10]
Benchmark automation - TCWG-360 [4/10]
* CPU2006 patches cleaned up, submitted
* A few other small fixes
Misc [3/10]
* ~1/10 getting a Juno running
=Plan=
Holiday next week, then:
Pick a direction on streaming vs listeners, write down the reasoning
Follow up (close out?) results storage and restricted targets
Write more tests, refactoring where appropriate
Investigate running benchmarks through ci.linaro.org
If time, and it looks sane, wrap a LAVA job around benchmark scripts
== Progress ==
LLDB development
-- Submitted and committed AArch64 hardware watchpoint/breakpoint
support [2/10] [TCWG-771]
-- Submitted Arm hardware watchpoint/breakpoint support [1/10] [TCWG-770]
-- Debugged arm watchpoints on Nexus 7 Android device. [2/10] [TCWG-651]
Miscellaneous [5/10]
-- Submitted AArch64 gdb record-replay patches
-- Travel to Islamabad for interview at French Embassy
-- Meetings, emails, discussions etc.
== Plan ==
LLDB development
-- Fix issues with hardware watchpoints and try to run tests on Nexus 7
-- Update and resubmit Arm hardware watchpoint patch.
== This week ==
* TCWG-619 (2/10)
- Disabling seccomp-bpf, works with LTO build for chromium for
multiple partitions (-flto-partitions={balanced, 1to1})
- disabling fPIC does not prevent the error - "branch out of range"
for single or no partition (--param lto-partitions=1 / -flto-partitions=none )
- The docs say there is option to disable PLT (-fno-plt),
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options
but using it results in unrecognized command line option.
* PR49551 (2/10)
- Found out why r221297 prevents the ICE:
merge_decl() calls make_decl_rtl() upon condtion DECL_RTL_SET_P (olddecl),
which causes the ICE. Before r221297, in merge_decls() DECL_RTL_SET_P
(olddecl) was true which resulted in call to make_decl_rtl() causing
ICE. After r221297, DECL_RTL_SET_P (olddecl) is 0, which doesn't
result in call to make_decl_rtl() so no ICE is produced. However,
DECL_COMMON is still incorrectly set in merge_decls() because it
copies newdecl into olddecl.
- Will post upstream for review after final testing on x86 and ARM.
* Misc (6/10)
- Exams
Short week (2 days off)
== Progress ==
o Upstream GCC (3/6)
* Flags for Cortex-a53 erratum #84341 workaround:
- Backported into FSF 4.9 and 5 branches
* Some cleanup to avoid format-security warnings
* TCWG-786 (LRA and PIC): Look for potential improvements
- nothing found so far.
o Linaro GCC release (2/6)
* Reviewed FSF branch merge into 4.8 branch
* Look at differences between our actual source tarball, and
the ones that can be created by ABE.
o Misc (1/6)
* Various meetings
== Plan ==
- Continue ongoing tasks
Benchmark automation - TCWG-360 [7/10]
* Convinced benchmark scripts to run entirely within LAVA
* Did a couple of benchmark runs for Kugan
* Cleaned up my CPU2000 patches and committed to central repository
Misc [3/10]
=Plan=
Clean up, commit CPU2006 patches
Pick a direction on streaming vs listeners, write down the reasoning
Follow up (close out?) results storage and restricted targets
Write more tests, refactoring where appropriate
If time, and it looks sane, wrap a LAVA job around benchmark scripts
== Progress ==
* Upstream GCC (5/10)
- committed delaying constant splitting in arm after full testing
(TCWG-486)
- Spec benchmarking is still an issue (TCWG-779)
- Bernie agreed to kindly help benchmark it
- taking time due to long lava queue
- Started working on widening pass based on review comments (TCWG-555)
- Wilco from ARM provided some test-cases and looking into it as well
* GCC bootstrap/build issues (4/10)
- Looked at bare-metal
- aarch-elf-none issue
- gcc bootstrap issue with ARM
- middle-end error
- Thanks to all, all now fixed in mainline.
* Misc (1/10)
- gcc-patches, gcc-bugs list
- Meetings
== Plan ==
- Continue with gcc stage1 activities
- Look at register allocation
# Progress #
* TCWG-517, GDB AAarch64 record/replay. Ongoing. [3/10]
Takes over from Omair, complete test cases and update patches.
Rewrite the test case using gcc inline assembly.
Happen to see that AAarch64 doesn't have CPSR register but
GDB thinks it has. This should be fixed separately later.
* Think about GDB version in next linaro toolchain release. [3/10]
The next linaro release is on July/Aug and the next GDB FSF release
7.10 will be on mid of June. I prefer to picking up 7.10, but need
Ryan or Maxim to make a decision.
* Exchange emails with Peter to push GDB kernel awareness work forward,
and think about how do that in next step. [1/10]
* Misc [3/10]
** Print and photocopy documents needed for France visa application.
# Plan #
* Go to France Embassy in London on Monday.
* GDB AAarch64 record/replay test and upstream submission.
--
Yao
Hi,
I tried on abe 'stable' branch and with below configuration build was
successful.
../abe/configure --with-fileserver=148.251.136.42 --with-remote-snapshots=
http://148.251.136.42/snapshots-ref
../abe/abe.sh --target aarch64-linux-gnu --build all
(Additionally I had to increase the wget_timeout=100)
But on master branch, with below commands (as suggested in above mail)
following error were observed.
../abe/configure --with-fileserver=148.251.136.42
--with-remote-snapshots=/snapshots-ref
../abe/abe.sh --target aarch64-linux-gnu --build all
ERROR (#144): fetch_http (md5sums doesn't exist and you disabled updating.)
Looks like following commit is causing problem on the abe master branch.
On removing it, build successfully downloaded the packages from
148.251.136.42.
commit 5a5ab3582851d52d903846d34c79850f5d7ebda5
don't try to fetch anything is updates are disabled.
Thanks
Virendra
On 6 May 2015 at 17:30, <linaro-toolchain-request(a)lists.linaro.org> wrote:
> Send linaro-toolchain mailing list submissions to
> linaro-toolchain(a)lists.linaro.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> or, via email, send a message with subject or body 'help' to
> linaro-toolchain-request(a)lists.linaro.org
>
> You can reach the person managing the list at
> linaro-toolchain-owner(a)lists.linaro.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of linaro-toolchain digest..."
>
>
> Today's Topics:
>
> 1. Re: 502 connecting to abe.tcwglab.linaro.org (Tim Entinger)
> 2. Re: 502 connecting to abe.tcwglab.linaro.org (Victor Chong)
> 3. [ANNOUNCE] Linaro GCC 4.9 2015.04 snapshot re-spin (Yvan Roux)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 5 May 2015 12:44:44 +0000 (UTC)
> From: Tim Entinger <timothy.entinger(a)jci.com>
> To: linaro-toolchain(a)lists.linaro.org
> Subject: Re: 502 connecting to abe.tcwglab.linaro.org
> Message-ID: <loom.20150505T143929-367(a)post.gmane.org>
> Content-Type: text/plain; charset=us-ascii
>
> Rob Savoye <rob.savoye@...> writes:
>
> >
> > On 04/21/2015 04:23 PM, Christopher Covington wrote:
> > > abe$ ./abe.sh --target aarch64-linux-gnu
> > > NOTE: Downloading md5sums to abe/snapshots
> > > RUN: /usr/bin/wget --timeout=10 --tries=2 --directory-
> prefix=abe/snapshots/ http://abe.tcwglab.linaro.org/snapshots/md5sums
> >
> > We're having a major security related issue, so the entire TCWG lab
> > got taken offline yesterday till this is fixed and more secured. No
> idea
> > what the ETA is for all of that. ABE will work regardless other than
> > some warning messages about not being able to download the md5sums
> file,
> > or anything under 'infrastructure'. Most of what ABE needs is at
> > git.linaro.org, and that's still online. The only files ABE downloads
> > from abe.tcwglab.linaro.org are source tarballs, which don't change
> very
> > often. As long as you have them already downloaded, you can build a
> > toolchain still. I work offline pretty frequently, so have tried to
> make
> > ABE work without the upstream access to anything.
> >
> > Try adding '--disable update' to your command line for abe.sh, and
> > it'll stop trying.
> >
> > - rob -
> >
> > _______________________________________________
> > linaro-toolchain mailing list
> > linaro-toolchain <at> lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> >
>
>
> Is there any update for when the TCWG lab will be back online? I was
> trying to use ABE for the first time and got the 503 Service Unavailable
> message. Is there a way to specify different locations for the source
> tarballs in the meantime? I'm hoping to work around the issue if a
> timeline is still unknown.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 5 May 2015 23:12:28 +0900
> From: Victor Chong <victor.chong(a)linaro.org>
> To: Tim Entinger <timothy.entinger(a)jci.com>
> Cc: Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>
> Subject: Re: 502 connecting to abe.tcwglab.linaro.org
> Message-ID:
> <CAHqM-QhhZw9hw33Mzf8iFtSDEdiX3NnLUMqvLt=v9JKHZgfa=
> Q(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Tim,
>
> On Tue, May 5, 2015 at 9:44 PM, Tim Entinger <timothy.entinger(a)jci.com>
> wrote:
>
> > Rob Savoye <rob.savoye@...> writes:
> >
> > >
> > > On 04/21/2015 04:23 PM, Christopher Covington wrote:
> > > > abe$ ./abe.sh --target aarch64-linux-gnu
> > > > NOTE: Downloading md5sums to abe/snapshots
> > > > RUN: /usr/bin/wget --timeout=10 --tries=2 --directory-
> > prefix=abe/snapshots/ http://abe.tcwglab.linaro.org/snapshots/md5sums
> > >
> > > We're having a major security related issue, so the entire TCWG lab
> > > got taken offline yesterday till this is fixed and more secured. No
> > idea
> > > what the ETA is for all of that. ABE will work regardless other than
> > > some warning messages about not being able to download the md5sums
> > file,
> > > or anything under 'infrastructure'. Most of what ABE needs is at
> > > git.linaro.org, and that's still online. The only files ABE downloads
> > > from abe.tcwglab.linaro.org are source tarballs, which don't change
> > very
> > > often. As long as you have them already downloaded, you can build a
> > > toolchain still. I work offline pretty frequently, so have tried to
> > make
> > > ABE work without the upstream access to anything.
> > >
> > > Try adding '--disable update' to your command line for abe.sh, and
> > > it'll stop trying.
> > >
> > > - rob -
> > >
> > > _______________________________________________
> > > linaro-toolchain mailing list
> > > linaro-toolchain <at> lists.linaro.org
> > > https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> > >
> >
> >
> > Is there any update for when the TCWG lab will be back online? I was
> > trying to use ABE for the first time and got the 503 Service Unavailable
> > message. Is there a way to specify different locations for the source
> > tarballs in the meantime? I'm hoping to work around the issue if a
> > timeline is still unknown.
> >
>
> We've setup an alternate server for the source tarballs for now. Configure
> master with '--with-fileserver=148.251.136.42
> --with-remote-snapshots=/snapshots-ref' to use it.
>
>
> >
> > _______________________________________________
> > linaro-toolchain mailing list
> > linaro-toolchain(a)lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> >
>
