linaro-toolchain

linaro-toolchain@lists.linaro.org

3 participants
5671 discussions

why ld.so in arm-linux-gnueabihf- toolchains search so many paths ?

by Barry Song

hi guys, sorry maybe my question is stupid as i am not a toolchain guy. i have no idea why ld.so search so many paths. for example, put "-rpath" with /home/cnb1szh/test in a simple test program. then during dynamic linking at runtime, we get the below linking debug information: 30693: find library=libmytest.so [0]; searching 30693: search path=/home/cnb1szh/test/tls/v7l/neon/vfp:/home/cnb1szh/test/tls/v7l/neon:/home/cnb1szh/test/tls/v7l/vfp:/home/cnb1szh/test/tls/v7l:/home/cnb1szh/test/tls/neon/vfp:/home/cnb1szh/test/tls/neon:/home/cnb1szh/test/tls/vfp:/home/cnb1szh/test/tls:/home/cnb1szh/test/v7l/neon/vfp:/home/cnb1szh/test/v7l/neon:/home/cnb1szh/test/v7l/vfp:/home/cnb1szh/test/v7l:/home/cnb1szh/test/neon/vfp:/home/cnb1szh/test/neon:/home/cnb1szh/test/vfp:/home/cnb1szh/test (RPATH from file ./hello) 30693: trying file=/home/cnb1szh/test/tls/v7l/neon/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/tls/v7l/neon/libmytest.so 30693: trying file=/home/cnb1szh/test/tls/v7l/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/tls/v7l/libmytest.so 30693: trying file=/home/cnb1szh/test/tls/neon/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/tls/neon/libmytest.so 30693: trying file=/home/cnb1szh/test/tls/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/tls/libmytest.so 30693: trying file=/home/cnb1szh/test/v7l/neon/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/v7l/neon/libmytest.so 30693: trying file=/home/cnb1szh/test/v7l/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/v7l/libmytest.so 30693: trying file=/home/cnb1szh/test/neon/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/neon/libmytest.so 30693: trying file=/home/cnb1szh/test/vfp/libmytest.so 30693: trying file=/home/cnb1szh/test/libmytest.so but we don't have /home/cnb1szh/test/tls/, /home/cnb1szh/test/v7l/, /home/cnb1szh/test/vfp/, /home/cnb1szh/test/neon/, why does the ld.so search so many paths? -barry

10 years, 2 months

Lost upstream patch in merge from gcc-5-branch to linaro/gcc-5-branch

by Robert Schiele

Hi, I found that with the merge commit ac19ac6481a3f326d9f41403f5dadab548b2c8a6 Author: Yvan Roux <yvan.roux(a)linaro.org> Date: Wed Sep 16 10:57:42 2015 +0200 Merge branches/gcc-5-branch rev 227732. Change-Id: I2f59904b28323b1c72a8cf1bd62c9e460d95bcea the following branch that was within merge range on gcc-5-branch was lost on the linaro branch: commit b45a5cf7c1544f95578e823e25402b58fb3fbedd Author: nsz <nsz@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Tue Aug 4 16:49:54 2015 +0000 Fix broken backport patch. gcc: Backport from mainline: 2015-08-04 Szabolcs Nagy <szabolcs.nagy(a)arm.com> PR target/66731 * config/aarch64/aarch64.c (aarch64_rtx_costs): Fix NEG cost for FNMUL. (aarch64_rtx_mult_cost): Fix MULT cost with -frounding-math. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-5-branch@226588 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index 691874b..eebc9c3 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -5250,7 +5250,7 @@ aarch64_rtx_mult_cost (rtx x, int code, int outer, bool speed) which case FNMUL is different than FMUL with operand negation. */ bool neg0 = GET_CODE (op0) == NEG; bool neg1 = GET_CODE (op1) == NEG; - if (compound_p || !flag_rounding_math || (neg0 && neg1)) + if (maybe_fma || !flag_rounding_math || (neg0 && neg1)) { if (neg0) op0 = XEXP (op0, 0); Since this was a fix to the patch one commit ahead and also merged in the same operation and there is no further comment on why this fix was skipped, may I assume that this happened by accident and you probably want to fix that merge flaw by reapplying the missing patch? Or is there an information detail I don't have that requires this fix to be skipped on the Linaro branch? Robert

10 years, 2 months

[ACTIVITY] 23rd - 27th November

by Bernie Ogden

Controlled image builds - TCWG-360 [1/10] * Tried, failed to generate bootable images Jenkins benchmarking job - TCWG-348 [5/10] * Jenkins job functional on kvms in main instance * Wrote job-dispatch script for non-Jenkins use cases Juno crashdump [1/10] * Struggled with, worked around network problems * Juno running, waiting for it to crash SPEC-on-Android [1/10] * Helped Qian to find root cause of a problem Misc [2/10] =Plan= Review security with shared uinstance/main instance code Expose more data, benchmarks to bundles Debug/test Jenkins job in microinstance Create bootable image for at least 1 target, or know what the problems are Write up noise control report (if time) Probably more support for SPEC-on-Android

10 years, 2 months

[ACTIVITY] 23 - 27 November 2015

by Yao Qi

# Progress # * Fix timeout in random-signal.exp. TCWG-424. Ongoing. [4/10] I know the cause of the problem but can't figure out why it can happen. Can only reproduce the fail in every 20~30 runs. * TCWG-423, support gnu vector in inferior call in AArch64 GDB. Done. [1/10] * Build native ARM and AArch64 GDB in C++. No regression in test. Done. TCWG-446. Done. [1/10]. * Fix GDB internal error in gdb.thread/watchpoint-fork.exp on AArch64. [2/10] * Upstream patches review [2/10] ** Review patches on arm gdbserver software single step V3. Some patches are approved, but V4 is also needed for the rest. ** Review all-stop on non-stop patches. ** Discuss whether we need single step in fast tracepoint. Ongoing. # Plan # * One day off on Monday. * Understand ST's jtag probe and help them to make use of multi-arch in GDB. * Look into timeout in random-signal.exp. * TCWG-156, GDB test parity between AArch64 and X86_64. * TCWG-460, follow up on the AArch64 GDBserver multi-arch work. -- Yao

10 years, 2 months

[ACTIVITY] 23 - 27 November 2015

by Kugan

== Progress == - tree re-assoc regression (2/10) - Found a test-case to reproduce it. - working on a patch - LuaJIT issue (6/10) * Setup luajit on aarch64 and tried it * tried to reproduce nginx issue with various configs without success - LTO (1/10) * aarch64 bootstrap * ran into an uninit warning issues looking into it - Misc (1/10) * gcc/bug list == Plan == * tree re-assoc * LTO

10 years, 2 months

[ACTIVITY]

by Renato Golin

== Progress == * Support (6/10) - Trying to add ADRL support in the assembler: http://llvm.org/PR24350 * Buildbots (1/10) - Some breakages, nothing serious * Background (3/10) - Code review, meetings, discussions, general support, etc. - Working on 2016's plan

10 years, 2 months

[ACTIVITY] Week 47

by Yvan Roux

== Progress == o Linaro GCC (4/10) * Found and backported missing dependencies * More backports o Upstream work (4/10) * Reviewed some patches * Tried to reproduced an LRA issue (fixed in the meantime) * Continue on sanitizing gfortran testsuite o Misc (2/10) * Various meetings == Plan == o Continue on-going tasks

10 years, 2 months

[ACTIVITY] 23 - 27 November 2015

by Prathamesh Kulkarni

== This Week == * Target conversion to hook (2/10) - Completed build and test for ASM_FORMAT_PRIVATE_NAME, ASM_LABEL_OUTPUT_LABEL to hook - Converted ASM_OUTPUT_LABEL_REF to hook * Holidays (8/10) - 3 days leave and public holiday (Guru nanak Jayanti) == Next Week == - Send updated patch upstream for tcwg-72 - LTO benchmarking with SPEC for correctness on arm and aarch64 - Target hook conversion

10 years, 2 months

[Weekly] 23-27 November 2015

by Michael Collison

== This week == * TCWG-317 - Exploit wide add operations when appropriate for Aarch32 (4/10) - Determined that big endian failure is unrelated to vaddw. - Bug filed upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68532 - Sent modified patch upstream for approval with caveat related to bugzilla 68532 * TCWG-369 - Exploit wide add operations when appropriate for Aarch64 (1/10) - Code checked in upstream. TCWG-369 is complete * Misc (1/10) - Conference calls * USA Thanksgiving Holiday (4/10) == Next week == * TCWG-316 - Additional investigation * TCWG-317 - Respond to upstream feedback * Bugzilla 68532 - Investigation

10 years, 2 months

[ANNOUNCE] Linaro Binary Toolchain Release GCC 5.2 2015.11

by Ryan Arnold

The Linaro Toolchain Working Group is pleased to announce the availability of the Linaro Stable Binary Toolchain GCC 5.2-2015.11 Release Archives. http://releases.linaro.org/components/toolchain/binaries/5.2-2015.11/ http://releases.linaro.org/components/toolchain/gcc-linaro/5.2-2015.11/ These archives provide cross-toolchain executables (compiler, debugger, linker, etc.) and shared libraries (libstdc++, libc, etc.) that target ARM or Aarch64 GNU/Linux and bare-metal environments. The cross-toolchain binaries execute on a Linux or MS Windows (under mingw32) host operating-system. Please evaluate this release-candidate for correctness. Linaro will shortly spin the Linaro GCC 5.2-2015.11 release if this release-candidate passes stakeholder validation. For bugs related to this release-candidate please email linaro-toolchain(a)lists.linaro.org or file a bug at https://bugs.linaro.org/enter_bug.cgi?product=Linux%20Binary%20toolchain NEWS * GCC 5.2 2015.11 The Linaro GCC 5.2 2015.11 binary toolchain release is built from the Linaro GCC-5.2-2015.11 release source archive. The Linaro GCC-5.2-2015.11 release source archive is derived from the same sources as the Linaro GCC-5.2-2015.10 snapshot source archive. * GCC 5.2 2015.11-rc1 The Linaro GCC 5.2 2015.11-rc1 binary toolchain release-candidate is built from the Linaro GCC-5.2-2015.11 release-candidate source archive. The Linaro GCC-5.2-2015.11-rc1 release-candidate source archive is derived from the same sources as the Linaro GCC-5.2-2015.10 snapshot source archive. -- Ryan S. Arnold Linaro Toolchain Working Group - Engineering Manager www.linaro.org

10 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain