[ANNOUNCE] Linaro Binary Toolchain Release GCC 4.9-2016.02
The Linaro Binary Toolchain The Linaro GCC 4.9-2016.02 Release is now available. Notice: All Linaro GCC 4.9 series toolchain users should migrate to the latest version of the Linaro GCC 4.9 toolchain in order to mitigate potential security exposure to CVE-2015-7545. See the NEWS section below for details. Download release packages from: http://releases.linaro.org/components/toolchain/gcc-linaro/4.9-2016.02/ http://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/ Previous snapshots and release-candidates are at: http://snapshots.linaro.org/components/toolchain/binaries/ Previous releases are at: http://releases.linaro.org/components/toolchain/binaries/ Host Requirements == Linaro officially supports the current and previous Ubuntu LTS releases (as of the time of this release). This does not mean that the toolchain will not work on other/older Linux distributions. See the following for the life-time of Ubuntu LTS releases. https://wiki.ubuntu.com/Releases The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc's memcpy API. https://bugs.linaro.org/show_bug.cgi?id=1869 Package Versions = Linaro GCC 4.9-2016.02 FSF eglibc 2.19 (eglibc.git/linaro_eglibc-2_19) Linaro newlib 2.1.0-2014.09 (linaro_newlib-branch) Linaro binutils 2.24 (linaro_binutils-2_24-branch) FSF GDB 7.10 (gdb-7.10-branch) Linaro Linux Version 3.17-2014.10 (linux-linaro-3.17-2014.10) Linaro toolchain package git branches are hosted at: http://git.linaro.org/?a=project_list&s=toolchain%2F&btnS=Search NEWS for Linaro GCC 4.9-2016.02 * The armv8l-linux-gnueabihf targetted toolchain is now built using --with-mode=thumb (like all of the other cross toolchains) rather than the default which is ARM mode. * Applied fix for CVE-2015-7545 - A stack-based buffer overflow in glibc's getaddrinfo() was corrected in glibc 2.23 and backported into Linaro eglibc 2.19 (linaro_eglibc-2_19). https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html * See the following Linaro GCC snapshot: http://snapshots.linaro.org/components/toolchain/gcc-linaro/4.9-2015.10/ Contact Linaro === File bugs at http://bugs.linaro.org For Linaro member support see http://support.linaro.org For Linaro community support email linaro-toolchain@lists.linaro.org -- Ryan S. Arnold | Linaro Toolchain Engineering Manager ryan.arn...@linaro.org | ryanarn on #linaro-tcwg @ freenode.irc.net ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Cross compilation issue
On Tue, Mar 29, 2016 at 11:12 PM, $rik@nth wrote: > Yes. I am using ubuntu 64bit to cross compile GCC to ARM. If i issue > --host=arm-linux-gnueabi then it will pick up default > /usr/arm-linux-gnuebi bins. I would like to pick up my binutils which > are built statically for doing some experiment. If binutils was built and installed with the same prefix as gcc, then gcc should automatically find and use it. For cross building a native, you need to build a cross compiler first, and then put it on your path, in which case the cross built native should use your cross compiler. > --host=arm-linux-gnueabi --target=arm-linux-gnueabi You have host and target, but not build. You should specify all three. > AR=arm-linux-gnueabi-ar CC=arm-linux-gnueabi-gcc > RANLIB=arm-linux-gnueabi-gcc-ranlib-4.7 STRIP=arm-linux-gnueabi-strip > CPP=arm-linux-gnueabi-g++ CXX=arm-linux-gnueabi-g++ You shouldn't have to specify stuff like this. These variables should be set automatically. > Now i am hitting one more issue before earlier one comes. > configure: error: cannot compute suffix of object files: cannot compile > See `config.log' for more details. > make[1]: *** [configure-build-libiberty] Error 1 You have to look at the config.log file to see what command failed. There is more than one config.log file. This would be the file build-$build/libiberty/config.log. This problem might be due to the missing --build configure option. if $build isn't x86_64-pc-linux-gnu or whatever your build machine is, then that is probably why the configure in this directory failed. Jim ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Question regarding the arm gcc 5.3 to build android
Hi folks,
I am trying to use arm gcc 5.3 to build part of android AOSP and hit
following issue with arm gcc 5.3:
The gcc cmd line is like:
/opt/work/acadine/mem_shrink/B2G-v2.5/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-5.3-linaro/bin/arm-linux-androideabi-g++
-I external/libcxx/include -I system/core/libbacktrace -I
out/target/product/linaro_arm/obj/SHARED_LIBRARIES/libbacktrace_intermediates
-I
out/target/product/linaro_arm/gen/SHARED_LIBRARIES/libbacktrace_intermediates
-I libnativehelper/include/nativehelper -I system/core/base/include -I
external/libunwind/include -isystem system/core/include -isystem
system/media/audio/include -isystem hardware/libhardware/include
-isystem hardware/libhardware_legacy/include -isystem
hardware/ril/include -isystem libnativehelper/include -isystem
frameworks/native/include -isystem frameworks/native/opengl/include
-isystem frameworks/av/include -isystem frameworks/base/include -isystem
out/target/product/linaro_arm/obj/include -isystem
bionic/libc/arch-arm/include -isystem bionic/libc/include -isystem
bionic/libc/kernel/uapi -isystem bionic/libc/kernel/uapi/asm-arm
-isystem bionic/libm/include -isystem bionic/libm/include/arm -c
-fno-exceptions -Wno-multichar -msoft-float -ffunction-sections
-fdata-sections -funwind-tables -fstack-protector -Wa,--noexecstack
-Werror=format-security -D_FORTIFY_SOURCE=2 -fno-short-enums
-no-canonical-prefixes -fno-canonical-system-headers -march=armv7-a
-mfloat-abi=softfp -mfpu=vfpv3-d16 -include
build/core/combo/include/arch/linux-arm/AndroidConfig.h -I
build/core/combo/include/arch/linux-arm/ -Wno-psabi -mthumb-interwork
-DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self
-Wpointer-arith -Werror=return-type -Werror=non-virtual-dtor
-Werror=address -Werror=sequence-point -DNDEBUG -g -Wstrict-aliasing=2
-fgcse-after-reload -frerun-cse-after-loop -frename-registers -DNDEBUG
-UDEBUG -fvisibility-inlines-hidden -DANDROID -fmessage-length=0 -W
-Wall -Wno-unused -Winit-self -Wpointer-arith -Wsign-promo -std=gnu++11
-Werror=return-type -Werror=non-virtual-dtor -Werror=address
-Werror=sequence-point -DNDEBUG -UDEBUG -mthumb -Os -fomit-frame-pointer
-fno-strict-aliasing -fno-rtti -Wall -Werror -fPIC -D_USING_LIBCXX
-std=gnu++11-Werror=int-to-pointer-cast
-Werror=pointer-to-int-cast -MD -MF
out/target/product/linaro_arm/obj/SHARED_LIBRARIES/libbacktrace_intermediates/UnwindCurrent.d
-o
out/target/product/linaro_arm/obj/SHARED_LIBRARIES/libbacktrace_intermediates/UnwindCurrent.o
system/core/libbacktrace/UnwindCurrent.cpp
And I got error:
/tmp/ccZ40ViQ.s: Assembler messages:
/tmp/ccZ40ViQ.s:1752: Error: selected processor does not support ARM
mode `cbnz r6,.L91'
/tmp/ccZ40ViQ.s:1758: Error: selected processor does not support ARM
mode `cbnz r0,.L92'
/tmp/ccZ40ViQ.s:1763: Error: selected processor does not support ARM
mode `cbz r1,.L107'
/tmp/ccZ40ViQ.s:1941: Error: selected processor does not support ARM
mode `cbz r6,.L100'
But if I use the arm gcc 4.9, there is no any build issue.
the "-dumpspecs" output of gcc 5.3 was attached. Thanks.
Regards
Yin, Fengwei
*asm:
%{mbig-endian:-EB} %{mlittle-endian:-EL} %(asm_cpu_spec) %{mapcs-*:-mapcs-%*}
%(subtarget_asm_float_spec) %{mthumb-interwork:-mthumb-interwork}
%{mfloat-abi=*} %{mfpu=*} %(subtarget_extra_asm_spec)
*asm_debug:
%{!g0:%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
*asm_final:
%{gsplit-dwarf:
objcopy --extract-dwo %{c:%{o*:%*}%{!o*:%b%O}}%{!c:%U%O}
%{c:%{o*:%:replace-extension(%{o*:%*} .dwo)}%{!o*:%b.dwo}}%{!c:%b.dwo}
objcopy --strip-dwo %{c:%{o*:%*}%{!o*:%b%O}}%{!c:%U%O} }
*asm_options:
%{-target-help:%:print-asm-header()} %{v} %{w:-W} %{I*}
%{gz|gz=zlib-gnu:--compress-debug-sections}
%{gz=none:--nocompress-debug-sections} %{gz=zlib:%e-gz=zlib is not supported in
this configuration} %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}
*invoke_as:
%{!fwpa*: %{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()}
%{!S:-o %|.s |
as %(asm_options) %m.s %A } }
*cpp:
%(subtarget_cpp_spec)
%{mfloat-abi=soft:%{mfloat-abi=hard:
%e-mfloat-abi=soft and -mfloat-abi=hard may not be used together}}
%{mbig-endian:%{mlittle-endian:
%e-mbig-endian and -mlittle-endian may not be used together}}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w}
%{f*} %{g*:%{!g0:%{g*} %{!fno-working-directory:-fworking-directory}}} %{O*}
%{undef} %{save-temps*:-fpch-preprocess}
*cpp_debug_options:
%{d*}
*cpp_unique_options:
%{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD
%{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*}
%{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ
%*}}} %{remap} %{g3|ggdb3|
Re: Question regarding the arm gcc 5.3 to build android
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
On Wed, Mar 30, 2016 at 9:12 PM, Jim Wilson wrote: > On Tue, Mar 29, 2016 at 11:12 PM, $rik@nth wrote: >> Yes. I am using ubuntu 64bit to cross compile GCC to ARM. If i issue >> --host=arm-linux-gnueabi then it will pick up default >> /usr/arm-linux-gnuebi bins. I would like to pick up my binutils which >> are built statically for doing some experiment. > > If binutils was built and installed with the same prefix as gcc, then > gcc should automatically find and use it. By default it is fetching pre-installed binutils while configure if i won't specify them to pick from where. > > For cross building a native, you need to build a cross compiler first, > and then put it on your path, in which case the cross built native > should use your cross compiler. > >> --host=arm-linux-gnueabi --target=arm-linux-gnueabi > > You have host and target, but not build. You should specify all three. >> AR=arm-linux-gnueabi-ar CC=arm-linux-gnueabi-gcc >> RANLIB=arm-linux-gnueabi-gcc-ranlib-4.7 STRIP=arm-linux-gnueabi-strip >> CPP=arm-linux-gnueabi-g++ CXX=arm-linux-gnueabi-g++ > > You shouldn't have to specify stuff like this. These variables should > be set automatically. You mean if i set --host=arm-linux-gnuebi and --target=arm-linux-gunebi should automatically pick cross compilers instead of pointing them? I am just following Linaro website on how to build cross tool chain https://wiki.linaro.org/WorkingGroups/ToolChain/BuildingGNUToolchains Please let me know if there is some more links where i can follow precisely. >> Now i am hitting one more issue before earlier one comes. >> configure: error: cannot compute suffix of object files: cannot compile >> See `config.log' for more details. >> make[1]: *** [configure-build-libiberty] Error 1 > > You have to look at the config.log file to see what command failed. > There is more than one config.log file. This would be the file > build-$build/libiberty/config.log. This problem might be due to the > missing --build configure option. if $build isn't x86_64-pc-linux-gnu > or whatever your build machine is, then that is probably why the > configure in this directory failed. > > Jim -- Thanks & Regards, M.Srikanth Kumar. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Cross compilation issue
On Wed, Mar 30, 2016 at 7:37 PM, $rik@nth wrote: > You mean if i set --host=arm-linux-gnuebi and > --target=arm-linux-gunebi should automatically pick cross compilers Yes, in theory, it should find CC, AS, AR, etc by itself. Don't forget that you need to set all 3 of build, host, and target for this to work. > instead of pointing them? I am just following Linaro website on how to > build cross tool chain > https://wiki.linaro.org/WorkingGroups/ToolChain/BuildingGNUToolchains That page only talks about a basic cross build. it doesn't talk about cross building a native. > Please let me know if there is some more links where i can follow precisely. We call it a "canadian cross" when build != host != target. What you are trying to do is very similar to a canadian cross, and works basically the same way. If you do a web search for "build canadian cross gcc" then you can find some web pages that talk about this. In general, this isn't well documented, because it is much harder to do a canadian cross than a regular cross, and it usually requires learning quite a bit about how gcc builds work in order to be able to do it successfully. We have a tool called ABE that we use for builds inside linaro. There is a wiki page for it at https://wiki.linaro.org/ABE I know that this has support for a windows canadian cross build, e.g. build=x86_64-linux host=i686-w64-mingw3 and then a target or arm or aarch64. I don't know offhand if it can be used for what you are trying to do. Building a native gcc binary is much easier than trying to cross build a native. You should do a native build if you can. 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
On Wed, Mar 30, 2016 at 6:26 PM, fengwei.yin wrote:
> Thanks a lot for your quick response. The .ii file was attached.
In UnwindFromContext, there is an asm that forces the assembler into ARM mode.
if (ucontext == nullptr) {
int ret = (({ unw_tdep_context_t *unw_ctx = (&context_); register unsigned \
long *unw_base asm ("r0") = unw_ctx->regs; __asm__ __volatile__ ( ".align 2\nbx\
pc\nnop\n.code 32\n" "stmia %[base], {r0-r15}\n" "orr %[base], pc, #1\nbx %[ba\
se]" : [base] "+r" (unw_base) : : "memory", "cc"); }), 0);
The ".code 32" puts us in ARM mode.
GCC still thinks that we are in thumb mode though, and continues to
emit thumb instructions, some of which have no arm mode equivalent,
e.g. cbnz and cbz.
I don't see any convenient push/pop for thumb/arm mode. This is
probably a macro expanded into the asm. You could have two versions
of the asm, one that gets used when __thumb__ is defined and one that
gets used when __thumb__ is not defined. The __thumb__ version would
switch back into thumb mode at the end with a ".thumb" pseudo-op.
Or alternatively, don't build with -mthumb.
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
Hi Jim,
On 2016/3/31 12:47, Jim Wilson wrote:
On Wed, Mar 30, 2016 at 6:26 PM, fengwei.yin wrote:
Thanks a lot for your quick response. The .ii file was attached.
In UnwindFromContext, there is an asm that forces the assembler into ARM mode.
if (ucontext == nullptr) {
int ret = (({ unw_tdep_context_t *unw_ctx = (&context_); register unsigned
\
long *unw_base asm ("r0") = unw_ctx->regs; __asm__ __volatile__ ( ".align 2\nbx\
pc\nnop\n.code 32\n" "stmia %[base], {r0-r15}\n" "orr %[base], pc, #1\nbx
%[ba\
se]" : [base] "+r" (unw_base) : : "memory", "cc"); }), 0);
The ".code 32" puts us in ARM mode.
GCC still thinks that we are in thumb mode though, and continues to
emit thumb instructions, some of which have no arm mode equivalent,
e.g. cbnz and cbz.
I don't see any convenient push/pop for thumb/arm mode. This is
probably a macro expanded into the asm. You could have two versions
of the asm, one that gets used when __thumb__ is defined and one that
gets used when __thumb__ is not defined. The __thumb__ version would
switch back into thumb mode at the end with a ".thumb" pseudo-op.
Or alternatively, don't build with -mthumb.
The thing is gcc 4.9 has no such problem. And I don't think it's possible to
disable thumb because it's a global flag for AOSP build.
I'd like to understand why Bero has no such issue in his side.
Regards
Yin, Fengwei
Jim
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
