All,
During Connect the suggestion was made that each working group should have
its own IRC Channel for discussions and topics relating to the group in
particular (as opposed to #linaro which is 'generic' Linaro conversations).
Therefore I have just set up #linaro-tcwg on Freenode for the Toolchain
Working Group.
This channel is public and open to anyone who wants to talk with the TCWG
group about anything toolchain related.
Thanks,
Matt
--
Matthew Gretton-Dann
Toolchain Working Group, Linaro
This seems like a tricky extension to deploy to the operating system.
What is the proposed interface for setting GP on application pages? There are
several things that seem plausible to me, and I wondered how far planning has
gotten.
An mmap/mprotect flag?
An ELF program header PT_ARM_BTI (a-la PT_GNU_RELRO) to direct the loader to
set said flag when mapping binaries? Or equivalently, a PF_MASKOS bit that
could be set on the normal PT_LOAD header.
An ELF section flag set by the compiler for sections that use -mbti, which are
then collected into the PT_GNU_BTI segment by the linker?
That seems like the most plausible way to indicate on a per-binary basis that
it has been compiled with the BTI hints in place. But probably there are other
ways that make an equal amount of sense.
Is there any coordination going on with Intel wrt their similar gadget
protection scheme(s)?
r~
== This Week ==
* SVE ACLE (8/10)
- WIP patches for svlsl_wide, integer comparisons and cls/clz.
* Public holiday (2/10)
== Next Week ==
- Continue ongoing tasks
[VIRT-327 # Richard's upstream QEMU work ]
Some tcg-op-gvec work in support of MCA's target/ppc AltiVec work.
But in the process filled in the blanks for target/arm to take
advantage of the new entry points.
Rebased my August linux-user split work, reorg'ed for advice, and
posted v5.
Reviewing Cota's dynamic sized tlb patch set. TODO: I want to update
the aarch64 backend for this before finalizing a data structure layout.
[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ]
Posted v1. We'll not talk about mailing lists any further. :-P
Merry Christmas, all!
r~
== Progress ==
* FDPIC
- (GNU-499) GCC: wait for feedback on v4 patches
- (GNU-411) GDB: it seems qemu's gdbstub needs patches to support
packets needed by fdpic. Tried to build gdbserver for fdpic, but the
code base changed a lot since our original port.
* GCC upstream validation:
- reported a few regressions
- dealing with some random results, still
- qemu-3.1.0-rc3, memory consumption: no time to really look at the
problem. Unable to match time's figures with LSF's
* GCC:
- (GNU-99) rebased ubsan / bare-metal patches. Using gcc-built
libubsan worked with an in-house llvm-based toolchain. POC is OK, but
a clean implementation is still far.
* misc (conf-calls, meetings, emails, ....)
- reviewing/submitted infra script patches
- dealing with nasty ST-internal infrastructure problems
- (GNU-592): improved benchmarking scripts
- looking at new build servers configs
== Next ==
FDPIC:
- GCC: handle feedback on v4 patches
- GDB: update patches
- uclibc-ng: look at how to test fdpic mode with openadk
Validation:
- isolate if/why qemu-3.1.0-rc3 consumes more memory than 2.11 for
aarch64-linux target
Posting this to an internal list because v8.5 is still NDA.
There are a lot of holes to be filled wrt the user-level ABI.
In the meantime, I have a cpu property to turn on GP for all
pages. Which means that to test it, I provide a complete
statically linked program, so that nothing uses indirect
branches except that the ones I use myself.
r~
Richard Henderson (11):
target/arm: Introduce isar_feature_aa64_bti
target/arm: Add PSTATE.BTYPE
target/arm: Add BT and BTYPE to tb->flags
target/arm: Record the GP bit for a page in MemTxAttrs
target/arm: Default handling of BTYPE during translation
target/arm: Reset btype for direct branches and syscalls
target/arm: Set btype for indirect branches
target/arm: Add guarded_pages cpu property for user-only
target/arm: Enable BTI for -cpu max
linux-user/aarch64: Reset btype for signal handlers
tests/tcg/aarch64: Add bti smoke test
include/exec/memattrs.h | 2 +
target/arm/cpu.h | 22 +++-
target/arm/internals.h | 6 +
target/arm/translate.h | 9 ++
linux-user/aarch64/signal.c | 4 +
target/arm/cpu64.c | 24 ++++
target/arm/helper.c | 28 +++--
target/arm/translate-a64.c | 196 +++++++++++++++++++++++++++++-
tests/tcg/aarch64/bti-1.c | 61 ++++++++++
tests/tcg/aarch64/bti-crt.inc.c | 51 ++++++++
tests/tcg/aarch64/Makefile.target | 7 +-
11 files changed, 399 insertions(+), 11 deletions(-)
create mode 100644 tests/tcg/aarch64/bti-1.c
create mode 100644 tests/tcg/aarch64/bti-crt.inc.c
--
2.17.2
=== Work done during the last week ===
* LLVM-432 (Support arithmetic on FileCheck regex variable): in progress
+ finished cleaning up code
+ rebase on top of trunk
+ fix all issues discovered with check-all
+ add detection of conflict between numeric variable and pattern variable
+ add memory management (yay for shared_ptr)
* GNU-593 (Tied softfloat mul and div): upstream review
+ search for a non-elf arm target
-> none seems supported
* Fix issues with -mslow-flash-data: committed
+ finish testing patch for big endian and respond to upstream comments
* GNU-598 (Do not select hardfloat when targeting Thumb-1 with mfpu
set): upstream review
+ write and test patch, submit upstream
* GNU-597 (pr77904.c test failure): upstream review
+ Investigate whether code added for PR77904 should be kept
+ test and submit patch for external review
=== Plan for week 51 ===
* DSGHACK-25 (Support arithmetic on FileCheck regex variable):
+ extend testcase coverage (add tests for latest syntax change and
add more negative testing)
+ clean up the code written last week
+ improve documentation
* Tied softfloat mul and div:
+ get it committed
* GNU-598 (Do not select hardfloat when targeting Thumb-1 with mfpu set):
+ get it committed
* GNU-597 (pr77904.c test failure):
+ get it committed
* Try to reproduce perf issue mentioned in week #30's weekly report on
latest perf
o 4 days week.
o GNU releases:
* Gave support for 6.5-2018.12-rc1
o LLVM
* Tested and uploaded 7.0.1-rc3 ARM and AArch64 binaries
* Machine Outliner on ARM prototype:
- Fixed a bug in tailcall handling on ARM
- Working on an issue with outlined calls through function pointers
o Misc
* Various meetings and discussions.
