linaro-toolchain April 2016

linaro-toolchain@lists.linaro.org

17 participants
41 discussions

by Yao Qi

# Progress # * TCWG-167, ARM reverse debugging bug fixes. [4/10] Four patches are committed. All FAILs are fixed if test case is compiled with -fomit-frame-pointer. Some FAILs when -fno-omit-frame-pointer are caused by epilogue unwinder doesn't parse epilogue correctly if FP is involved. File TCWG-562 to track it. * TCWG-545, TCWG-547, patches are pending. Maintainer is busy on something else. * Triage the regression gdb.base/jit.exp. [1/10] We need a pending patch series to address this issue. Ask Pedro how to review them. * TCWG-561, handle unavailable memory during frame unwinding. [3/10] Think about it and write a prototype. * Misc, patches review and meeting, [2/10]. # Plan # * Take a look at the slow native arm-linux-gnueabihf gdb test. * TCWG-562, Tweak epilogue unwinder to handle FP. * TCWG-545, TCWG-547, ping. * TCWG-561, finish the prototype. -- Yao

8 years, 7 months

Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

by Gunnar Arndt

My dear friends, I'm trying to build C++ code for Linux running on am ARM Cortex A8 (TI AM335x). For a first try, I'm using the simplest program I can think of: /* main.cpp */ int main() { return 0; } Under Linux with the 'normal' GCC, that works fine, but under Windows 7 with the Linaro toolchain, it fails with the following message: C:\firedect\dev\workspace\Test-Linux-ARM_1> "\Program Files (x86)\GNU Tools ARM Embedded\gcc-linaro-4.9-2016.02-i686-ming w32_arm-linux-gnueabi\bin\arm-linux-gnueabi-g++.exe" main.cpp c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/lib/libstdc++.so: file format not recognized; treating as linker script c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/lib/libstdc++.so:1: syntax error collect2.exe: error: ld returned 1 exit status C:\firedect\dev\workspace\Test-Linux-ARM_1> "\Program Files (x86)\GNU Tools ARM Embedded\gcc-linaro-5.3-2016.02-i686-ming w32_arm-linux-gnueabihf\bin\arm-linux-gnueabihf-g++.exe" main.cpp c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so: file format not recognized; treating as linker script c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program files (x86)/gnu tools arm embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1: syntax error collect2.exe: error: ld returned 1 exit status As you can see, I have tested two versions of the toolchain, which show the same behavior. Do you have any idea what's going wrong here? I'd appreciate any help you can provide! -- Kind regards, Gunnar Arndt

8 years, 7 months

Another weird behavior with arm gcc 5.3

by fengwei.yin

Hi list, I hit another weird problem after use gcc 5.3 (If I use gcc 4.9, there is no any issue) with android. With arm gcc 5.3, the C++ apps crash in one class constructor call. And gdb shows some vtbl items of the class are not relocated. With arm gcc 4.9, if set breakpoint in that constructor, we could see the vtbl items of the class are relocated. And Yes. I know the android bionic loader take response to do relocation. But if it works with gcc 4.9, I suppose bionic loader work well (unless gcc 5.3 create some new situation not handled by it). I attached the vtbl dump in gdb for gcc 5.3 and 4.9 both. We could see all valid entries in vtbl are relocated in 4.9 dump. But not all entries in vtbl are relocated in 5.3 dump (the address is not started with 0xf). Suggestions/hints are welcome. Thanks a lot. Regards Yin, Fengwei

8 years, 7 months

[ACTIVITY] 27 March to 1 April 2016

by kugan

== Progress == * Type promotion pass (4/10) - Tested many different architectures - Branch created - Getting ready to benchmark * LTO (2/10) - Read VRP algorithms - new - Discussing algorithm implementation * Bugs (1/10) - PR70359 * Misc (1/10) - GCC Lists - Jenkins benchmarking jobs * Public holiday (2/10) == Plan == * LTO and VRP

8 years, 7 months

Re: Question regarding the arm gcc 5.3 to build android

by Jim Wilson

On Thu, Mar 31, 2016 at 5:12 AM, fengwei.yin <fengwei.yin(a)linaro.org> wrote: > Because gcc 4.9 could build this file without any issue, I apply > --save-temps > with gcc 4.9. The ii file is attached. Can't see significant differences. There is a patch in gcc-5 to make unified assembler syntax the default. Unfortunately, it changes how extended asms work, which is perhaps a bug. The message claims it doesn't affect extended asms, but it does. https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01196.html The interesting bit is the change to ASM_APP_OFF. gcc-4.9 emits a .thumb after the extended asm to switch back into thumb mode just in case. gcc-5.3 instead emits .syntax unified, which doesn't change the arm/thumb mode, just the syntax supported. This is arguably a bug, but this doesn't immediately help you. It could take a little time to get gcc-5.x source fixed, and then the compiler binary releases. Or alternatively we could fix the asm to work with gcc 5. Jim

8 years, 7 months

[ACTIVITY] Week 13

by Yvan Roux

== Progress == o Extended validation (7/10) * Fixed and improved extended native validation * Discussed proposed patch in dejagnu on process killing mechanism * Testing a fix/workaround in GCC guality tests * Re-implemented and tested fix for dejagnu remote layout o Misc (3/10) * Various meetings == Plan == o Continue on extended validation o Finalize DejaGNU patches, GCC ARMv8.1 builtins fix.

8 years, 7 months

[Weekly] 28 March - 01 Apr

by Michael Collison

== This week == * Bugzilla 69008 - gcc emits unneeded memory access when passing trivial structs by value (ARM) (3/10) - Additional investigation and preliminary implementation * Bugzilla 70089 - ARM/THUMB unnecessarily typecasts some rvalues on memory store (1/10) - Investigation * TCWG-247 - Create Validation Job to run on GCC Trunk Committ (5/10) - Began writing shell script. * Misc meeting (1/10) == Next week == * TCWG-247 - Make additional prgoress on prototype * Bugzilla 69008 - gcc emits unneeded memory access when passing trivial structs by value (ARM) - Additional investigation and preliminary implementation * Bugzilla 70089 - ARM/THUMB unnecessarily typecasts some rvalues on memory store - Investigation * Vacation - April 8 - April 12

8 years, 7 months

[ACTIVITY]

by Renato Golin

== Progress == * Holiday (2/10) * Support (1/10) - Reapplying fix for PR16275 (D18701) - Conclusion is that original approach will be the same as GCC - Additional flags will have to be agreed upon across compilers * Buildbot (2/10) - Setting up LLDB buildbot with Omair - Precarious infrastructure is unstable, hope it holds on until the new rack is complete * Background (5/10) - Code review, meetings, discussions, general support, etc. - More team management stuff (access/procedure/meeting with newcomers) - Planning the lab move, resources, costs, schedule

8 years, 7 months

[ACTIVITY] 28 March -- 01 April

by Yao Qi

* Monday off [2/10] # Progress # * TCWG-167, ARM reverse debugging bug fixes. [4/10] Two patches are posted. Two patches are being tested. They fix 207 FAILs (242 -> 35) in gdb.reverse. * TCWG-545, no progress, patches are pending for review. * TCWG-547, [2/10]. Write a patch as Pedro suggested, so we have sense which patch is better. No response. * Misc, [2/10] ** Upstream discussions on get syscall number on execve exit. Can't get such thing from kernel side, need to figure out how to do it in GDB side. ** Investigate a little bit on 32-bit DWARF on AArch64. # Plan # * TCWG-167, TCWG-545, TCWG-547 -- Yao

8 years, 7 months

[ACTIVITY] 28 March-1 April 2016

by Christophe Lyon

* Monday off (2/10) == Progress == * Validation - extended validation - dejagnu and stdout/stderr possible races * GCC - reported a few regressions in trunk and gcc-5 branch - a few backports * Misc (confi-calls, meetings, emails, ....) == Next == * Validation - extended validation - more on dejagnu stdout/stderr & random results * GCC: - trunk monitoring, report regressions if needed - intrinsics tests cleanup - backports

8 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain April 2016