=== Work done during this past week ===
* GNU-296 / GCC PR85434 / CVE-2018-12886:
+ few more issues fixed and associated testing
+ now also running Thumb-1 bootstrap and testing
* Prepare patch to further update cpus and architectures in bfd
* Line management
=== Plan for week 43 ===
* GNU-296 / GCC PR85434 / CVE-2018-12886:
+ finish testing, and submit new stack protector patch for upstream review
* LLVM-432 (Support arithmetic on FileCheck regex variable):
+ extend testcase coverage (add tests for latest syntax change and
add more negative testing)
+ finish cleaning up the code
* Try to reproduce perf issue mentioned in week #30's weekly report on
latest perf
* Line management
Progress:
* VIRT-65 [QEMU upstream maintainership]
- code review
- use ID registers as master source for "should this CPU
have this feature" information (rth)
- clean up 32-bit Neon to use vector infrastructure (rth)
- don't let the kernel get loaded on top of our builtin
bootloader if it happens to ask for a zero text offset
- Xilinx Versal board patches
- target-arm pull requests
- some minor patches to fix new clang warnings
- preparation for KVM Forum/QEMU Summit etc next week
thanks
-- PMM
== Progress ==
* FDPIC
- GCC: handled feedback on v3 patches.
Not much info on how to test other existing uclinux targets.
Noticed that GCC trunk build fails when targeting cortex-m23
(v8-m.baseline), problems in support libs (libgcc, newlib)
* GCC upstream validation:
- reported a few regressions
- dealing with some random results, again
* GCC:
- bug report on aarch64 about misaligned accesses. Waiting for more
details to reproduce the problem.
* misc (conf-calls, meetings, emails, ....)
== Next ==
FDPIC:
- GCC: discuss v3 patches where the way forward is not clear yet
- uclibc-ng: look at how to test fdpic mode with openadk
- use qemu-system mode to run more tests
[LLVM-203] (was TCWG-1424, we've moved issues to a new project)
Started writing up results to close out this investigation.
- Reran some sample profiling test cases with a higher sample rate.
- Investigated why some test cases exploded in code-size with LTO.
- Got some results for thin LTO (broadly similar to LTO).
- Discovered that I need to pass in extra linker options to enable LTO
to use the new pass manager, sample profiling and setting of
optimisation level.
-- Need to rerun these configurations over the weekend.
- Have most of the surrounding text of the report written, now need to
work on presentation of results.
[TCWG-1473] Fix big-endian linux kernel builds for AArch32
Now committed upstream
Holiday Friday
o LLVM
* Machine Outliner on ARM prototype:
- Still debugging Thumb1 issues in Spec2K6
- Investigating issues in PIC mode
* Bots babysitting
o Misc
* Various meetings and discussions.
[VIRT-214 # SVE System Registers ]
Posted v3 patch set.
[VIRT-281 # Extend gdbstub for SVE ]
Crashed gdb. Posted patch fixing buffer overrun.
It was suggested to me that qemu's gdbstub might not support enough
modern bits of the remote protocol for SVE. So I spent quite a bit
of time reading up on the protocol and beginning to review
[PATCH v2 00/15] gdbstub: support for the multiprocess extension
In the end I'm not convinced there's anything missing for SVE.
I think I'm going to have to examine upstream gdb more closely,
running gdbserver proper.
[Upstream]
Collecting patches for tcg-next.
Misc patch review.
[GCC]
Pinged my LSE patch set from 2 Oct.
r~
== Progress ==
* FDPIC
- GCC: send v3 patches, got some feedback: will need another iteration
* GCC upstream validation:
- reported a few regressions
- dealing with some random results, again
* GCC:
- looking at bug report on aarch64 about misaligned accesses. Need
more details to reproduce the problem
* Newlib
- got a few small patches accepted
* misc (conf-calls, meetings, emails, ....)
== Next ==
FDPIC:
- GCC: handle v3 patches feedback
- uclibc-ng: look at how to test fdpic mode with openadk
=== Work done during this past week ===
* TCWG-1428 (Support arithmetic on FileCheck regex variable):
+ continued cleaning up code and painfully rebased it on recent trunk
* GNU-296 / GCC PR85434 / CVE-2018-12886:
+ fixed changes to routines for PIC access to use specified register
+ fixed 2 more issues in stack protector new instruction patterns
+ testing for arm and thumb2, now starting over due to one of the above issues
* GNU-580 / PR86968: in progress
+ investigate, try 2 approaches, need to start looking into 3rd approach
* Line management.
=== Plan for week 42 ===
* GNU-296 / GCC PR85434 / CVE-2018-12886:
+ finish testing, and submit new stack protector patch for upstream review
* TCWG-1428 (Support arithmetic on FileCheck regex variable):
+ extend testcase coverage (add tests for latest syntax change and
add more negative testing)
+ finish cleaning up the code
* GNU-580 / PR86968: in progress
+ attempt 3rd approach
* Try to reproduce perf issue mentioned in week #30's weekly report on
latest perf
* Line management:
+ continue progress on rotations
+ start preparing first AFDS
[TCWG-1473] Fix -fno-integrated-as and -mbig-endian (Linux Kernel
Build with clang)
- Needed some revision to handle linker emulation. Patch in upstream review
[TCWG-1474] Fix out of range branch (CBZ) when -fimplicit-it (or
-fno-integrated-as) and certain kinds of inline assembly
- Committed upstream.
[TCWG-1424] Code-size investigations with PGO
- Marking functions for size optimisation at the earliest possible
stage improves code-size for little loss in performance. The main
beneficiary is that loops are not unrolled in size optimised functions
and inline thresholds are lower.
- LTO with instrumented profiling still sees large increase in size.
Originally thought my changes weren't working with LTO but I think
that something else is happening.
-- Found out that the profiling information isn't being sent to the
LTO code-generator (although it should be present as IR annotations
from the objects.
-- There is an option to pass the sample profile through to the LTO
code-generator but not an instrumented profile file.
-- It seems like the LTO plugin doesn't use the new pass manager
unless a separate option is passed through to the code-generator.
-- It seems like Thin-LTO is where most of upstream development is
these days and there is a slightly different pass pipeline, and some
interaction with profiling. Worth some more experiments.
First draft made of incorporating YVR18 Jira discussion into
Confluence https://collaborate.linaro.org/display/TCWG/JIRA+Usage+and+Best+Practices
