linaro-toolchain

linaro-toolchain@lists.linaro.org

6 participants
5578 discussions

[ACTIVITY] 10-14 November 2014

by Christophe Lyon

1 day off (2/10) == Progress == * Linaro GCC 4.8 - updated branch merge, to include the latest errata-related backport - added Michael's backport for bug #534. * GCC trunk/4.9 cross-validation (2/10) - updated vbic/vorn tests patch - trying to track down cause of spurious 'interrupted system call' errors in the ST Compute Farm * AArch64 sanitizer (1/10) - After discussing with Arnd, the kernel patch causing trouble to libsanitizer should also be backported to stable kernel branches. This makes a compiler test based on kernel version impracticable. - Shared this feedback with sanitizer maintainers, got no feedback. - libsanitizer maintainers have updated GCC's snapshot with a more recent version: - GCC trunk now requires updated kernel headers for aarch64 - reported regressions when the compiler generates Thumb code (incomplete backtrace) * Neon intrinsics tests (2/10) - submitted a series of 9 new tests. - looking at vldX bugs on aarch64_be, along with ARM's incomplete patches. * cbuild2 - no progress * Misc (3/10) - calls, meetings, support == Next == * AArch64 sanitizers * Neon intrinsics * cbuild2 (improve backport-test and tcwgweb)

10 years, 6 months

[ANNOUNCE] Linaro GCC 4.9 and 4.8 2014.11 released

by Yvan Roux

The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2014.11 stable release of both Linaro GCC 4.9 and Linaro GCC 4.8 source packages. With the imminent release of ARMv8 hardware and the recent release of the GCC 4.9 compiler the Linaro TCWG will be focusing on stabilization and performance of the compiler as the FSF GCC compiler. The Linaro TCWG provides stable[1] quarterly releases and monthly engineering[2] releases. Linaro GCC 4.9 2014.11 is the eighth Linaro GCC source package release and second stable one in the 4.9 series. It is based on FSF GCC4.9.3-pre+svn216979 and includes performance improvements and bug fixes. Interesting changes in this GCC source package release include: * Updates to GCC 4.9.3-pre+svn216979 * Backport of [AArch64] Fix ILP32 ld.so * Add new Linaro release macros : __LINARO_RELEASE__ and __LINARO_SPIN__ Linaro GCC 4.8 2014.11 is the fifteenth release in the 4.8 series and second one since entering maintenance. Based off the latest GCC 4.8.4-pre+svn217270 release, it includes performance improvements and bug fixes. Interesting changes in this GCC source package release include: * Linaro bugzilla PR fixed : #307, #534 * Updates to GCC 4.8.4-pre+svn217270 * Add new Linaro release macros : __LINARO_RELEASE__ and __LINARO_SPIN__ Feedback and Support Subscribe to the important Linaro mailing lists and join our IRC channels to stay on top of Linaro development. ** Linaro Toolchain Development "mailing list": http://lists.linaro.org/mailman/listinfo/linaro-toolchain ** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@ * Bug reports should be filed in bugzilla against GCC product: http://bugs.linaro.org/enter_bug.cgi?product=GCC * Questions? "ask Linaro": http://ask.linaro.org/. * Interested in commercial support? inquire at "Linaro support":mailto: support(a)linaro.org [1] Stable source package releases are defined as releases where the full Linaro Toolchain validation plan is executed. [2] Engineering source package releases are defined as releases where the compiler is only put through unit-testing and full validation is not performed.

10 years, 6 months

[Question] Should gdb client query FP registers even if gdb server does not report having org.gnu.gdb.aarch64.fpu feature?

by Qu, Strong

Hello, We have implemented gdb server in one of our project and we are using Linaro aarch64-none-elf-gdb.exe as gdb client. Our gdb server will response to packet 'qXfer:features:read:target.xml:0,fff' with a xml file which only claims feature 'org.gnu.gdb.aarch64.core'. However, when I issue 'info reg' command with the gdb client, it actually sends out a packet '$p42#d6', which is trying to read fpsr if I understand correctly. Is this an expected behavior or not? I just want to figure out whether our gdb server send some bad info to the gdb client and made the client thinks FP registers are valid. I hope I made my question clear and I'm really appreciate if anybody can help us on this again. Thanks, Strong

10 years, 6 months

Separate out code used by a pager in OP-TEE

by Jens Wiklander

Hi toolchain champions, [please keep me in cc as I'm not subscribed to linaro-toolchain(a)lists.linaro.org] In OP-TEE we are going to activate a pager which is an integrated part of the statically linked secure OS binary (compiled for ARMv7/Aarch32 now, but at some point also Aarch64). The pager in OP-TEE allows use of more memory than the amount of available physical memory. This makes it possible to for instance have an OP-TEE binary that requires more memory than the amount of available memory. What the pager does is to map a physical page at the virtual address where the memory is needed and populate it which what is expected on demand. The pager also unmaps physical pages that hasn't been used in a while to be able to recycle it. The code used by the pager to map and populate a page must always be mapped since we would otherwise get a deadlock. The problem is that the pager is also part of OP-TEE so we need to partition the binary in a way that all code needed to handle a page fault is in one area in the binary and always mapped. Annotating functions and such as it's done in the Linux kernel with __init will not scale here since the pager will need routines from "third-party" libraries. We can make small changes to the libraries but identifying and annotating everything needed by the pager is too much. We would also run into troubles with strings. I have a couple ideas below that I need help exploring. What if we do an incremental linking of the entire TEE Core with garbage collect only keeping the entry functions of the pager? Then we would get an object file with everything the pager depends on included but not much more. It would be easy to put this single object file in a separate part of the OP-TEE binary. The procedure would be something like: Compile everything with -ffunction-sections -fdata-sections ld -i --gc-sections -u pager_entry -o pager_code.o $(objs) $(link-ldadd) $(libgcc) ld $(link-ldflags) pager_code.o $(objs) $(link-ldadd) $(libgcc) But the problem comes with linking in the rest of the code in the last step, we would get lots of multiple defined symbols. We could create a libtee_core.a file where we put all the $(objs) files and the linker would only use the needed object files. But we would still have some multiple defined symbols left since each .o file contains more than just one section. Any ideas how to solve this? We could perhaps split each .o file into several .o files each with only one section. Would it work? Would it make the resulting binary larger or inefficient? Another option could be to mark all symbols in libtee_core.a and other libaries as weak, but the problem here is that we already have some weak functions in TEE Core so this would break that. Perhaps if it would be possible to have different levels of weakness. Any ideas are welcome, either along this path or different approaches. Regards, Jens

10 years, 6 months

[ACTIVITY] 3 - 7 November 2014

by Omair Javaid

== Progress == AArch64 work on tracepoints and watchpoints failures [4/10] -- Review of AArch64 debug hardware architecture -- AArch64 debugging/testing stalled due to lab down time -- Tried compiling and running custom AArch64 kernel with foundation model Work on some arm specific fix of reverse-step and reverse-finish commands. [TCWG-498] [1/10] Miscellaneous [1/10] -- Meetings, Emails etc -- Prepared Hong Kong visa documents -- Annual Review 2014 Public Holidays [4/10] == Plan == Complete documents and travel to Islamabad for Hong Kong visa Resume AArch64 work on tracepoints and watchpoints failures with lab availability.

10 years, 6 months

[ACTIVITY] 3 - 7 November 2014

by Will Newton

== Progress == * Pushed malloc microbenchmark to glibc (1/10, TCWG-160) * Upstream work (4/10, CARD-341) - glibc patch review (C11 atomics series) - glibc patchwork cleanup * Look into binutils input fuzzing fixes (1/10) * Investigate ARM port of lld (2/10) * Email, meetings, review, etc. (2/10) == Issues == * Installed new cable modem. Seems to be working... == Plan == * Plan toolchain ILP32 work * lld investigation -- Will Newton Toolchain Working Group, Linaro

10 years, 6 months

[ACTIVITY] 3-7 November

by Charles Baylis

== Progress == Bug 404 [5/10] Bugs 403/418 [2/10] Misc [3/10] . office move . review

10 years, 6 months

[ACTIVITY] 3rd - 7th November

by Bernie Ogden

cbuild2 benchmarking - TCWG-360 [4/10] * SPEC 2006 cross-built binaries now running. Easy when you know how. libm exercising - CARD-1693 [4/10] * Understood improved libm usage on 1 benchmark. * Tried 3 more. 1 shows significantly more time in libm on AArch64 over AArch32. Meetings/mail/etc - [2/10] =Plan= cbuild2 benchmarking * Make sure reporting works * Get working in either LAVA or 'new TCWG infrastructure' * Test repeatability * Get SPEC 2000 working * Possibly have another go at building tools on AArch64 libm exerising * Keep working through the list of benchmarks * Hopefully reach the end and do some analysis

10 years, 6 months

[ACTIVITY] Week 45

by Yvan Roux

== Issues == * none. == Progress == * GCC 4.9 and 4.8 2014.11 (1/10) - Reviewed FSF branch Merges. * Lab move (3/10) - Cherry-picked cbuildv2 master patches in schroot-test - Created a new jenkins job to tst the "schroot lab move" branch - The job is able to build all the targets but validation still not works * Misc: (6/10) - Caught up with mails and irc logs - Prepared a patch that add __LINARO_[RELEASE|SPIN]__ macros. - Reviewed libatomic_ops upstream patch - Validate libunwind upstream patch - Various meetings. == Plan == * Back on backports * Tuesday off (11/11)

10 years, 6 months

[ACTIVITY] 3 - 7 November 2014

by Venkataramanan Kumar

= Progress == * TCWG-544 - Investigate core mark performance with both at -O3 with LTO + PGO (6/10) Different IPA inline decisions happening between Linaro and trunk. No major differences in other IPA passes. Trunk Inlines crcu32 and not inlines crcu16. Inlining crcu16 decreases instruction count. Honza pointed out a patch which inlines fucntions based on profile feedback and ignores max inlines parameters. It could be reason why trunk inlines crcu32 and then prevents inlining crcu16. Need to explore on this. * Bug fix - Linaro 849. Reproduced and tested it with trunk revision which fixes it. It looks to be same issue as upstream pr62308 (1/10) * Misc [3/10] Emails, linaro and AMD status meetings. 1-1 with inline mangers (Mev, Ryan). 1-1 with christophe. == Plan == * Debug and understand the inline differences trunk vs linaro compiler for core mark at -O3 with LTO + PGO. * Expecting one Aarch64 Enablement task. * Leave on 11/11/2014.

10 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain