Holiday [2/10]
Benchmark Automation - TCWG-360 [4/10]
* Learned about central Jenkins instance
* Considered ways of integrating benchmark scripts with said instance
* Considered alternative way for benchmark scripts to interoperate with LAVA
Misc [4/10]
* Large mail backlog
* Travel prep
=Plan=
Team sprint
# Progress #
* Linaro GDB [4/10]
** TCWG-805, aarch64 native debugging multi-arch support.
aarch64 native gdb is able to debug arm program now, but with some
problems on coredump. Patches are not posted.
** Give my input on GDB kernel awareness too, and the proposal finally
is posted upstream.
* FSF GDB [1/10]
** Patches review.
* Misc [5/10]
** Attend an internal ARM Debug/Tracing summit.
** Prepare for the France travel.
# Plan #
* Sprint in Grenoble.
--
Yao
Hi Linaro Toolchain Group,
I am trying to build a cross-native toolchain for AARCH64 using ABE build
framework.
By cross native I mean that toolchain will be build on 0x86 (Red hat
Santiago 6.4), it will run on AARCH64 (Juno) and
will produce binaries to be run on AARCH64 (Juno)
(If I am not mistaked) --build=0x86, --host=AARCH64, --target=AARCH64
Steps followed:
1. I built a cross toolchain first
../abe/configure
../abe/abe.sh --target aarch64-linux-gnu --build all --release 2015.05.29
--tarbin --disable update
2. Added the above cross toolchain (bin path) in the PATH
3. To build to cross-native
../abe/configure
../abe/abe.sh --host aarch64-linux-gnu --target aarch64-linux-gnu --build
all --release 2015.06.01.native --tarbin --disable update
But after some time, I got following error and compilation hanged.
make: Leaving directory
`/home/user_name/vpathak/build_abe/builds/aarch64-linux-gnu/aarch64-linux-gnu/gcc.git~linaro-4.9-branch-stage1'
RUN: copy_gcc_libs_to_sysroot
"/home/user_name/vpathak/build_abe/builds/destdir/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
--sysroot=/home/user_name/vpathak/build_abe/sysroots/aarch64-linux-gnu"
/home/user_name/vpathak/abe/lib/make.sh: line 962:
./builds/destdir/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc: cannot
execute binary file
Am I missing something ? Please help.
However with the following hack in the abe, I am able to compile
cross-native toolchain for aarch64-linux-gnu.
In the abe code base:
-------------------------------------------------------------------------------------------------------
lib/make.sh
Function copy_gcc_libs_to_sysroot()
gcc_exe="`find -name ${target}-gcc`"
- libgcc="`${gcc_exe} -print-file-name=${libgcc}`"
+ #libgcc="`${gcc_exe} -print-file-name=${libgcc}`"
+
libgcc="/home/user_name/vpathak/build_abe/builds/destdir/aarch64-linux-gnu/lib/gcc/aarch64-linux-gnu/4.9.3/libgcc.a"
Since './builds/destdir/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc' is
native toolchain it will not run on 0x86. Thus libgcc will be empty.
Therefore I hard-coded libgcc path.
-------------------------------------------------------------------------------------------------------
I had to disable gdb compilation. This error I faced while compiling
cross-native compilation only.
Cross compilation is successful on the same 0x86 machine.
checking for library containing waddstr... no
configure: error: no enhanced curses library found; disable TUI
make: *** [configure-gdb] Error 1
make: Leaving directory
`/home/user_name/vpathak/build_abe/builds/aarch64-linux-gnu/aarch64-linux-gnu/binutils-gdb.git~linaro_gdb-7.8-branch-gdb'
WARNING: Make had failures!
ERROR (#159): build_all (Failed building .)
hacked patch
--- a/lib/make.sh
+++ b/lib/make.sh
@@ -31,10 +31,10 @@ build_all()
# to rebuilt the sysroot.
local builds="infrastructure binutils libc stage2 gdb"
else
- local builds="infrastructure binutils stage1 libc stage2 gdb"
+ local builds="infrastructure binutils stage1 libc stage2"
fi
if test "`echo ${target} | grep -c -- -linux-`" -eq 1; then
- local builds="${builds} gdbserver"
+ local builds="${builds}"
fi
---------------------------------------------------------------------------------------------------------------
Thanks.
--
with regards,
Virendra Kumar Pathak
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
