Progress: [short week, 3 days]
* VIRT-65 [QEMU upstream maintainership]
+ code review
- RTH's FP16 bugfixing patchset
- Alex's float-to-float conversion patchset
- fixes to SD card CRC checking
- various minor linux-user cleanups
* VIRT-164 [improve Cortex-M emulation]
+ working on emulation of Memory Protection Controller: have a working
prototype that needs a few loose ends tidied up
thanks
-- PMM
Hi, Maxim
Do we have any build for native aarch64 toolchain GCC 7.3?
I checked snapshots.linaro.org:
https://snapshots.linaro.org/components/toolchain/gcc-linaro/7.3-2018.04/
But it only has x86 versions.
Somebody pinged me from the 96boards community to ask for that. He
asked for GCC 7.3. What being used in ERP 17.12, as I checked, is GCC
6.3.
Thank you very much.
Best regards,
Guodong Xu
Progress:
[Upstream]
* Push tcg patch queue
* Posted v2 of ARMv8.2-FP16 fixes
[VIRT-243 # ARMv8.1-Atomic instructions ]
* Posted v3 of the patch set.
Passes the gcc testsuite.
[VIRT-198 # QEMU: SVE Emulation Support ]
* I now have a set of gcc testsuite failures
that are unequivocally SVE vector issues.
r~
o 2 days off
== Progress ==
o GNU releases
* Some support to MM.
* Monthly snapshots deployed.
o LLVM
* Benchmarking job still on-going
* Investigating Thumbv8 bot failures
o Misc
* Various meetings and discussions.
[Activity]
[TCWG-1384]
- Implemented missing TLS LE relocations in LLD
- Found out while testing that LLVM had the range check in locally
resoloved fixups for Thumb2 BL wrong, and was not range checking B.w
or Bcc.W at all. Patches submitted for review.
[LLD]
- Submitted extra test cases to improve code-coverage
- Arm LLD 2 stage build-bot including test suite now configured
(thanks Maxim!), will be active upstream soon.
- Started to think about how ICF could be implemented in clang
-- Should be able to make a prototype using clang libtooling
[TCWG-1236]
- Added aarch64 emulation used by Android to LLD
- Tried and failed to get Android to boot when using LLD, narrowed
down the number of modules that could be problematic but I think that
the main symptom is dlopen failing on some modules.
- Found that Google have added LLD support to the Android build system
with a very slightly tweaked version of LLD. This will successfully
boot Android. The main differences are:
-- Google's LLD is a few weeks behind trunk.
-- They have reverted a couple of patches that add undefined symbols
from Shared Objects and allow these to resolve against static
libraries. These patches are correct and I think it is just exposing
some library dependency problems in Android.
-- They are setting -zmax-page-size to 4K on AArch64, LLD defaults to 64K.
--- Android dynamic linker does use 4K page size, but Gold still
seems to use a 64K max page size and I can't see why overaligning
would cause problems.
-- A handful of modules have LLD disabled.
[Plans]
- Investigate differences in trunk and Google Android LLD to see if I
can pinpoint why trunk is failing to boot Android.
- Start to build a prototype with libtooling that records when the
address of a function/member-function/lambda is taken.
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ code review:
- RTH's v8.1 atomics emulation patchset
- bugfix to cmsdk UART model
- bugfix to MPUIR access check for OMAP/StrongARM emulation
- Alex's float-to-float conversion refactoring
- SMMUv3 now fully reviewed and in target-arm.next
+ tracked down a bug in our handling of "DUP" vector instruction
that turned out to be in the new x86 codegen backend that tries
to use MMX instructions and wasn't quite getting it right. Patch sent.
* VIRT-164 [improve Cortex-M emulation]
+ working on emulation of Memory Protection Controller; I think we can
do this neatly using QEMU's IOMMU emulation framework, but it needs
some improvements to the framework to make that work:
- feed memory transaction attributes to the IOMMU translate function
so it can use secure/nonsecure attribute to make decisions
- allow TCG code to handle accessing data and executing from RAM
that's on the far side of an IOMMU (currently it asserts if you
set up a system with an IOMMU in the CPU's data path)
I have some prototype patches that deal with these and use them in an MPC
model, which need debugging.
thanks
-- PMM
- Off Tuesday (May 1st)
== Progress ==
* GCC
- FDPIC
- GCC: updating patches to handle new target name: lots of
testsuite and target libs configure changes needed.
- QEMU: patches merged in master, thanks to Peter's reviews.
* GCC upstream validation:
- reported a few new failures/regressions
* Infrastructure:
- patch reviews
- stopped trying to use TK1s until they are back in Jenkins
- cleanup
- tcwg-1404: small patches to prepare use of slaves outside our VPN
* misc (conf-calls, meetings, emails, ....)
== Next ==
* very short week (only Monday)
* FDPIC:
- GCC continue cleanup
* GCC upstream validation
