== Progress ==
LLDB development
-- Fixed thumb mode issues if user triggers changes to PC register
[TCWG-228] [3/10]
-- Triage of testsuite failures on armel chromebook [TCWG-228] [2/10]
-- Update xfail decorators for arm-linux targets. Marked traiged as
xfail. [TCWG-494] [3/10]
Miscellaneous [1/10]
-- Meetings, emails, discussions etc.
Half Day Leave [1/10]
-- Tooth extraction surgery.
== Plan ==
LLDB development
-- Triage more failures on armel chromebook [TCWG-228]
-- Submit an updated xfail decorator for arm-linux. [TCWG-494]
Miscellaneous
-- Connect visa follow up.
== This Week ==
* tcwg-72 (2/10)
- Following Jim's suggestions using XEXP (remainder, 0) worked to
resolve segfault
for DImode case
- Resolved ICE's due to (silly) mistakes.
* PR69133 (4/10)
- Reduced test-case following Markus's suggestions.
- I think it happens because node->lto_file_data is set to NULL in
lto_free_function_in_decl_state_for_node ().
Commenting out the following calls from get_untransformed_body():
lto_free_section_data (file_data, LTO_section_function_body, name,
data, len, decl_state->compressed);
lto_free_function_in_decl_state_for_node (this);
prevents the ICE. I suppose symbols with same name in same partition
share state (?), so setting lto_file_data = NULL
affects state of 2nd occurence of symbol and we hit the assert.
If this is true, gating on lto_file_data doesn't seem unreasonable IMO
to avoid ICE (the code anyway has undefined behavior due to violation of ODR).
I am still not sure why this "works" for partitioning enabled (one,
balanced, 1to1).
* 447.deallII bug (1/10)
- Bug not reproducible (verified with Kugan).
* TCWG-319 benchmarking (1/10)
- first job submission failed due to kernel panic
- a53: base fp run completed, with-patch in progress
* Misc (2/10)
- Meetings
- ipa
== Progress ==
* Validation
- a couple of fixes in the validation jobs
- improvements to the comparison scripts
* GCC
- investigated bugs #1980 and #1982.
Reverted the backports that introduced the problem.
- TCWG-485/PR68620: resumed
- TCWG-484: target attributes problems in the testsuite.
Sent an updated patch, but Christian has also submitted
a patch which modifies the compiler behavior. I'll have
to update mine when his patch is accepted.
* Misc (conf calls, meetings, emails, ....)
== Next ==
* Validation: more cleanup. Hopefully start extending validation scope
* GCC:
- bug fixing
- check trunk regressions reported during the holidays
== Progress ==
* Support (2/10)
- Having a go at PR25722, too hacky for a feature that can
be easily worked around.
- Reviewing some kernel issues with Arnd
* Planning (6/10)
- Drafting 2 year plans for LLVM
* Background (2/10)
- Code review, meetings, discussions, general support, etc.
- Catching up from long holidays
# Progress #
* Handle input interrupt in GDB. TCWG-424. Done. [3/10]
Need to update GDB manual to clarify the expected behaviour of GDB.
* Estimate the effort of GDB kernel-awareness work. Done. [1/10]
* TCWG-491. Ongoing. [2/10]. Understand symbol handling
in GDB.
* Various patch review upstream. [2/10].
* Clean up code on arm software single step after some changes from
Ericsson. Ongoing. [2/10].
# Plan #
* TCWG-491.
* Follow up of TCWG-424 to update GDB manual.
* Clean up code on arm software single step.
* Assess the ARM and AArch64 GDB test result, as 7.11 release is
coming soon.
--
Yao
Is it in the 2015.11-1 release ?
- rob -
-------- Original message --------
From: Jim Wilson <jim.wilson(a)linaro.org>
Date: 01/05/2016 19:45 (GMT-07:00)
To: Xiaofeng Ren <xiaofeng.ren(a)nxp.com>
Cc: linaro-toolchain(a)lists.linaro.org, Zhenhua Luo <zhenhua.luo(a)nxp.com>
Subject: Re: gcc-linaro-5.1 vs gcc-linaro-4.8
On Tue, Jan 5, 2016 at 4:19 PM, Xiaofeng Ren <xiaofeng.ren(a)nxp.com> wrote:
> Hello Jim,
> Appreciate for your comments.
> I will try to manually apply that patch on my side and try it.
> BTW, may I know which released Linaro gcc version include that patch? Maybe I can download it and try it quickly.
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00025.html
It was backported to our gcc-5 branch on Nov 24 by Yvan. This is
after the latest release 2015-11 was made. The patch is in the
December snapshot, but I think that is a source only release.
http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.3-2015.12/
You would have to build your own toolchain from that, perhaps by using abe.
Jim
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain(a)lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro TCWG,
In newer toolchains that are built with ABE, libc.a contains a lot of debugging information, including the paths to the source files on the build machine. I think that's because ABE builds the libraries with -g and never strips out the debug information. I verified this with both the 4.9-2015.05 and 5.2-2015.11 binary releases with the command:
arm-linux-gnueabih-objdump -g libc.a | grep '\.c'
In older toolchains that were built with crosstool-ng, libc.a did not contain the paths to the source files. I guess crosstool-ng either didn't build the libraries with -g, or it stripped out the debug information later. I verified this with the 4.9-2014.09 binary release.
I'm not sure whether this change was intentional, or just an oversight during the switchover to ABE. Regardless, it makes the libraries a lot bigger, and it potentially affects the end user during debugging.
The source files of libc, etc. are not typically included with the binary releases. So, when a user of an ABE-built binary release chooses to step into an extern function of libc, gdb will search for the source file. It likely won't be able to access the source file along the same path that worked for the build machine, so it will search its list of source directories. Ultimately, unless the user has downloaded the source files, gdb will likely display a message like "printf.c: No such file or directory".
In contrast, when a user of a crosstool-ng-built toolchain tries to step into an extern function of libc, gdb will be unaware of the name of the source file. As a result, the user will not get a message about a missing file.
So, should the toolchains' libraries really contain debug information? I think it could be useful for a theoretical multilib folder that covers a -g option. On the other hand, for the usual release builds, isn't the debug information a waste of space and a source of confusion?
Thanks,
Fred Peterson
Engineer - Developer Tools
NXP Semiconductors
Hello All,
I found one difference between gcc-linaro-5.1 vs gcc-linaro-4.8 while I'm doing lmbench benchmark test for our LS1043 (cortex-A53).
While using gcc-linaro-4.8, gcc will generate advanced SIMD instructions (like as ld1, etc), however, gcc-linaro-5.1 will not generate advance SIMD instructions. This will cause big performance gap between gcc-4.8 and gcc-5.1 for lmbench memory bandwidth "fcp" test (bw_mem program).
My compiler flags is "-O3 -mcpu=cortex-a53". I also tried several different compiler flags ("-O3 -mcpu=cortex-a53+fp+simd", "-O2 -ftree-vectorize -mcpu=cortex-a53", "-O3 -ftree-vectorize -mcpu=cortex-a53"), all of them doesn't work.
Gcc-5.1 toolchain was downloaded from following link:
https://snapshots.linaro.org/openembedded/sources/gcc-linaro-5.1-snapshot-2…
Can I have your comments on this?
Thanks
Ron
Hello toolchain gurus,
In the course of Linaro's kernel tinification project, the ability to
compile the Linux kernel using LTO is a frequent requirement. However
the kernel makes heavy usage of 'ld -r' with .o files resulting from LTO
build of .c files as well as .o files resulting from pure assembly code.
This mix of LTO and non-LTO object files is not supported by upstream
binutils unless a patch from H.J. Lu is applied. That patch has been
available since 2013 and was last refreshed in his 2.25.51.0.4 branch
last September. It is accessible here:
https://git.linaro.org/toolchain/binutils-gdb.git/commit/6da5456971
I've attached a very simple test case demonstrating the problem. With
the binutils-lto-mixed.patch applied, this test case compiles to a
working executable. Otherwise compilation fails at the 'ld -r' step.
One question and one request:
- What, if anything, has prevented this patch from being merged in the
master branch upstream?
- In the mean time, could we include this patch in the Linaro binutils
package and releases?
Having this available in our toolchain releases would greatly simplify
the LTO related work on the kernel. It was included in all binutils
releases from H.J. Lu since 2013 and therefore has obtained significant
exposure already.
Thanks.
Nicolas
