linaro-toolchain

linaro-toolchain@lists.linaro.org

7 participants
5634 discussions

getting armv7 linker to emit armv4t thumb interworking

by Allen Martin

I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to. I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something? -Allen nvpublic

13 years, 5 months

[PATCH] ld: add switch to disable use of BLX instructions

by Allen Martin

Add --no-use-blx switch to force disabling of BLX instructions for thumb interworking. This allows ld to emit code that is armv4t safe even if configured for armv5 or later. --- bfd/bfd-in.h | 4 ++-- bfd/bfd-in2.h | 4 ++-- bfd/elf32-arm.c | 10 +++++++++- ld/emultempl/armelf.em | 11 +++++++++-- 4 files changed, 22 insertions(+), 7 deletions(-) diff --git a/bfd/bfd-in.h b/bfd/bfd-in.h index a477b49..0a81327 100644 --- a/bfd/bfd-in.h +++ b/bfd/bfd-in.h @@ -872,8 +872,8 @@ extern bfd_boolean bfd_elf32_arm_process_before_allocation (bfd *, struct bfd_link_info *); void bfd_elf32_arm_set_target_relocs - (bfd *, struct bfd_link_info *, int, char *, int, int, bfd_arm_vfp11_fix, - int, int, int, int, int); + (bfd *, struct bfd_link_info *, int, char *, int, int, int, + bfd_arm_vfp11_fix, int, int, int, int, int); extern bfd_boolean bfd_elf32_arm_get_bfd_for_interworking (bfd *, struct bfd_link_info *); diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h index 22fcdf6..45c5376 100644 --- a/bfd/bfd-in2.h +++ b/bfd/bfd-in2.h @@ -879,8 +879,8 @@ extern bfd_boolean bfd_elf32_arm_process_before_allocation (bfd *, struct bfd_link_info *); void bfd_elf32_arm_set_target_relocs - (bfd *, struct bfd_link_info *, int, char *, int, int, bfd_arm_vfp11_fix, - int, int, int, int, int); + (bfd *, struct bfd_link_info *, int, char *, int, int, int, + bfd_arm_vfp11_fix, int, int, int, int, int); extern bfd_boolean bfd_elf32_arm_get_bfd_for_interworking (bfd *, struct bfd_link_info *); diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c index 1f6c1a0..7cbb5f8 100644 --- a/bfd/elf32-arm.c +++ b/bfd/elf32-arm.c @@ -2782,6 +2782,9 @@ struct elf32_arm_link_hash_table /* Nonzero if the ARM/Thumb BLX instructions are available for use. */ int use_blx; + /* Nonzero to prevent BLX instructions from being used. */ + int no_use_blx; + /* What sort of code sequences we should look for which may trigger the VFP11 denorm erratum. */ bfd_arm_vfp11_fix vfp11_fix; @@ -3332,6 +3335,7 @@ elf32_arm_link_hash_table_create (bfd *abfd) #endif ret->fix_v4bx = 0; ret->use_blx = 0; + ret->no_use_blx = 0; ret->vxworks_p = 0; ret->symbian_p = 0; ret->use_rel = 1; @@ -5939,7 +5943,9 @@ check_use_blx (struct elf32_arm_link_hash_table *globals) cpu_arch = bfd_elf_get_obj_attr_int (globals->obfd, OBJ_ATTR_PROC, Tag_CPU_arch); - if (globals->fix_arm1176) + if (globals->no_use_blx) + globals->use_blx = 0; + else if (globals->fix_arm1176) { if (cpu_arch == TAG_CPU_ARCH_V6T2 || cpu_arch > TAG_CPU_ARCH_V6K) globals->use_blx = 1; @@ -6800,6 +6806,7 @@ bfd_elf32_arm_set_target_relocs (struct bfd *output_bfd, char * target2_type, int fix_v4bx, int use_blx, + int no_use_blx, bfd_arm_vfp11_fix vfp11_fix, int no_enum_warn, int no_wchar_warn, int pic_veneer, int fix_cortex_a8, @@ -6825,6 +6832,7 @@ bfd_elf32_arm_set_target_relocs (struct bfd *output_bfd, } globals->fix_v4bx = fix_v4bx; globals->use_blx |= use_blx; + globals->no_use_blx = no_use_blx; globals->vfp11_fix = vfp11_fix; globals->pic_veneer = pic_veneer; globals->fix_cortex_a8 = fix_cortex_a8; diff --git a/ld/emultempl/armelf.em b/ld/emultempl/armelf.em index d29da59..14a0dcf 100644 --- a/ld/emultempl/armelf.em +++ b/ld/emultempl/armelf.em @@ -36,6 +36,7 @@ static int target1_is_rel = 0${TARGET1_IS_REL}; static char *target2_type = "${TARGET2_TYPE}"; static int fix_v4bx = 0; static int use_blx = 0; +static int no_use_blx = 0; static bfd_arm_vfp11_fix vfp11_denorm_fix = BFD_ARM_VFP11_FIX_DEFAULT; static int fix_cortex_a8 = -1; static int no_enum_size_warning = 0; @@ -462,7 +463,7 @@ arm_elf_create_output_section_statements (void) bfd_elf32_arm_set_target_relocs (link_info.output_bfd, &link_info, target1_is_rel, - target2_type, fix_v4bx, use_blx, + target2_type, fix_v4bx, use_blx, no_use_blx, vfp11_denorm_fix, no_enum_size_warning, no_wchar_size_warning, pic_veneer, fix_cortex_a8, @@ -533,6 +534,7 @@ PARSE_AND_LIST_PROLOGUE=' #define OPTION_NO_MERGE_EXIDX_ENTRIES 316 #define OPTION_FIX_ARM1176 317 #define OPTION_NO_FIX_ARM1176 318 +#define OPTION_NO_USE_BLX 319 ' PARSE_AND_LIST_SHORTOPTS=p @@ -547,6 +549,7 @@ PARSE_AND_LIST_LONGOPTS=' { "fix-v4bx", no_argument, NULL, OPTION_FIX_V4BX}, { "fix-v4bx-interworking", no_argument, NULL, OPTION_FIX_V4BX_INTERWORKING}, { "use-blx", no_argument, NULL, OPTION_USE_BLX}, + { "no-use-blx", no_argument, NULL, OPTION_NO_USE_BLX}, { "vfp11-denorm-fix", required_argument, NULL, OPTION_VFP11_DENORM_FIX}, { "no-enum-size-warning", no_argument, NULL, OPTION_NO_ENUM_SIZE_WARNING}, { "pic-veneer", no_argument, NULL, OPTION_PIC_VENEER}, @@ -567,7 +570,7 @@ PARSE_AND_LIST_OPTIONS=' fprintf (file, _(" --target2=<type> Specify definition of R_ARM_TARGET2\n")); fprintf (file, _(" --fix-v4bx Rewrite BX rn as MOV pc, rn for ARMv4\n")); fprintf (file, _(" --fix-v4bx-interworking Rewrite BX rn branch to ARMv4 interworking veneer\n")); - fprintf (file, _(" --use-blx Enable use of BLX instructions\n")); + fprintf (file, _(" --[no-]use-blx Disable/enable use of BLX instructions\n")); fprintf (file, _(" --vfp11-denorm-fix Specify how to fix VFP11 denorm erratum\n")); fprintf (file, _(" --no-enum-size-warning Don'\''t warn about objects with incompatible\n" " enum sizes\n")); @@ -625,6 +628,10 @@ PARSE_AND_LIST_ARGS_CASES=' use_blx = 1; break; + case OPTION_NO_USE_BLX: + no_use_blx = 1; + break; + case OPTION_VFP11_DENORM_FIX: if (strcmp (optarg, "none") == 0) vfp11_denorm_fix = BFD_ARM_VFP11_FIX_NONE; -- 1.7.5.4

13 years, 5 months

[ACTIVITY] report week 15

by Peter Maydell

Current Milestones: || || Planned || Estimate || Actual || ||cp15-rework || 2012-01-06 || 2012-04-10 || || Historical Milestones: ||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 || ||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 || == cp15-rework == * completed last of the register conversions, started on the final check-through and polish before it goes out to the mailing list * implemented changes following review of the clean-up-reset patchset == other == * qemu-linaro 2012.04 final testing (confirming an audio issue on the vexpress model LP:977610 wasn't a regresion) and release * patch review: pl330 dma controller model * patch review: samsung's sd card model overhaul * minor patch: fix compile failure on bsd * minor patch: fix failure to reset timer on a9 mptimer reset * minor patch: diagnose attempts to use python3 at configure time * sent arm-devs.next pullreq * put together a bug report in the form of a youtube video (!) as requested by the gmail folks -- PMM

13 years, 5 months

[ACTIVITY] Apr 11 - Apr 13

by Ulrich Weigand

== GCC == * Committed fix for LP #968766 (PR tree-optimization/52880) to FSF mainline and Linaro GCC 4.6 and 4.7. * Created merge reqest to fix LP #972648 for Linaro GCC 4.6 by backporting mainline patch; pending approval. * Updated patch to use vld1.64/vst1.64 instead of vldm/vstm for vector moves. Testing detected problems in GCC core memory alignment logic (GCC assumes vector types are naturally aligned, which contradicts ARM ABI and ARM back-end assumptions). Started discussion on possible fixes. * Updated and retested patch to use vld1/vst1 to implement vec_set/vec_extract for cases where the scalar operand resides in memory. * Ongoing work on fixing LP #959242. * Ongoing work on improving end-of-loop value computation. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

13 years, 5 months

Linaro GDB 7.4 2012.04 released

by Thiago Jung Bauermann

The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.4 2012.04. Linaro GDB 7.4 2012.04 is the second release in the 7.4 series. Based off the latest GDB 7.4, it includes a number of ARM-focused bug fixes and enhancements. Interesting changes include: * gdbserver can now be compiled with Android's toolchain. * Additional fixes from the GDB 7.4 branch, one of them being that it doesn't require makeinfo to build anymore. The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.4-2012.04 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- []'s Thiago Jung Bauermann Linaro Toolchain Working Group

13 years, 5 months

[ANNOUNCE] Linaro QEMU 2012.04 released

by Peter Maydell

The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2012.04. Linaro QEMU 2012.04 is the latest monthly release of qemu-linaro. Based off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes and enhancements. New in this month's release: - ppoll syscall now supported in ARM linux-user mode - the SETEND instruction in the Thumb encoding now UNDEFs to match behaviour for the ARM encoding - the OMAP36xx UART FIFO status registers are now implemented (thanks to Jan Vesely) Known issues: - Graphics do not work for OMAP3 based models (beagle, overo) with 11.10 Linaro images. - Audio may not work on Versatile Express models with the latest Linaro kernel/hardware packs (LP:977610). The source tarball is available at: https://launchpad.net/qemu-linaro/+milestone/2012.03 More information on Linaro QEMU is available at: https://launchpad.net/qemu-linaro

13 years, 5 months

[ANNOUNCE] Linaro GCC 4.7 and 4.6 2012.04 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the 2012.04 release of both Linaro GCC 4.7 and Linaro GCC 4.6. Linaro GCC 4.7 2012.04 is the first release in the 4.7 series. Based off the latest GCC 4.7.0+svn186061 release, it includes performance improvements especially around 64 bit operations. Interesting changes include: * Our first 4.7 based release * Updates to GCC 4.7.0+svn186061 * Better use of 16 bit Thumb-2 instructions for smaller code size * Implements 64 bit ones complement in NEON * Adds support for the ARMv6 saturation instructions * Backports the NEON lexer improvements for faster compilation * Backports the 64 bit multiply, divide, and mod improvements Fixes: * LP: #960283 slp pass assert when compiler configure with --enable-checking Linaro GCC 4.6 2012.04 is the fourteenth release in the 4.6 series. Based off the latest GCC 4.6.3+svn186060 release, this is the first release after entering maintenance. Interesting changes include: * Updates to 4.6.3+svn186060 Fixes: * LP: #960283 slp pass assert when compiler configure with --enable-checking The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.7-2012.04 https://launchpad.net/gcc-linaro/+milestone/4.6-2012.04 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro More information on the features and issues are available from the release page: https://launchpad.net/gcc-linaro/4.7/4.7-2012.04 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain Bugs: https://bugs.launchpad.net/gcc-linaro/ Questions? https://ask.linaro.org/ Interested in commercial support? Inquire at support(a)linaro.org -- Michael

13 years, 5 months

O2 optimization with vectorize

by Singh, Ravi Kumar (Ravi)

All, In the below code, I tried few compiler options and got following observations: 1) arm-linux-gnueabi-gcc -O2 -mcpu=cortex-a15 -mfpu=neon -ftree-vectorizer-verbose=6 -ftree-vectorize Compiler throws following info messages: foo.c:16: note: not vectorized: unsupported use in stmt. foo.c:16: note: not vectorized: unsupported use in stmt. foo.c:18: note: not vectorized: unsupported use in stmt. foo.c:18: note: not vectorized: unsupported use in stmt. 2) -O2 -mcpu=cortex-a15 -mfpu=neon None of the generated code contains the NEON instructions. Code generated with case 1 is taking 3000 cycles, and code generated by option 2 is taking 2500 cycles. Even if vectorization failed in case1, it should not generate more inefficient code than case 2. My belief was that the executables from both would take same cycles, any thing done for doing unsuccessful vectorization must be reverted if it did not succeed. ################################################################### #define SIZE1 20 #define SIZE2 26 unsigned int array[SIZE1][SIZE2]; void foo() { unsigned int i,j; unsigned int max = 0; for(i = 0; i < SIZE1; i++) { for(j = 0; j < SIZE2; j++) { if (array[i][j] > max) { max = array[i][j]; index = j; } } } printf("Max value: %u Index: %u\n", max, index); } Regards RKS

13 years, 5 months

2012.04 release prep

by Michael Hope

Hi there. The 2012.04 toolchain release is this week. Ulrich, I see your fix for LP: #968766 has been approved upstream. In theory it's too late but I'm happy to land it if you are. Could you decide and let Andrew know by the middle of Tuesday? Andrew, if you don't hear from Ulrich then spin away. Andrew, could you run the release process on Tuesday please? There's one extra step this month: once you've uploaded and spawned the job, go to the scheduler screen and click on 'Release' beside each of the ursas. I reserved them to make sure they'd be idle and ready to pick up the release build when ready. Thiago, let us know if Ulrich or I can lend a hand with the GDB release. -- Michael

13 years, 5 months

Changing the time of the fortnightly performance call

by Ramana Radhakrishnan

Hi there, At the last call Michael asked if we could push this call back by 30 minutes given the changes due to daylight savings. Does anyone have any objections to a new time of 10 a.m. BST - 11 a.m. Central European - 9 p.m. New Zealand. ? cheers Ramana

13 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain