QEMU Tooling ([VIRT-252])
=========================
QEMU plugin support ([VIRT-280])
- posted {PATCH v3 0/3} softmmu demacro Message-Id:
<20190215143115.28777-1-alex.bennee(a)linaro.org>
- looks like there is still a bug on x86 TCG Message-Id:
<20190219182528.GA19925@flamenco>
- started v4 re-base, but realised we need better testing so
- posted {PATCH v2 00/16} Enabling tcg/tests for cris and system
mode xtensa & arm Message-Id:
<c3a65d4b-8720-2957-1394-032823a78760(a)redhat.com>
- started writing an i386 test case (x86 exercises more of the
softmmu edge cases)
- started reviewing v3 of plugin patches
[VIRT-280] https://projects.linaro.org/browse/VIRT-280
Upstream Work ([VIRT-109])
==========================
- posted {PATCH v5} hw/block: better reporting on pflash backing file
mismatch Message-Id: <20190227111347.15063-1-alex.bennee(a)linaro.org>
- tested the possible ahci/migrate fix Message-Id:
<20190227121052.GD2602@work-vm> for hang identified last week
- posted {PULL 0/7} softfloat updates, mostly for s390x Message-Id:
<20190226141201.16999-1-alex.bennee(a)linaro.org>
- posted {PATCH v1 0/6} current state of gitdm/next Message-Id:
<20190226164656.mhasc4xxfjf34hns@function>
- and follow-up {PATCH v2 0/5} gitdm/next updates Message-Id:
<20190301100310.22345-4-alex.bennee(a)linaro.org>
- added some stats to VIRT-26/VIRT-326 for possible KPI use
[VIRT-109] https://projects.linaro.org/browse/VIRT-109
Other
=====
- more drafting of Connect talk
Completed Reviews [1/1]
=======================
{PATCH v2 00/11} pflash: Fixes and cleanups
Message-Id: <20190226193408.23862-5-armbru(a)redhat.com>
- CLOSING NOTE [2019-03-01 Fri 16:59]
Looks like a good cleanup
Absences
========
- Connect BKK19 (1-5th April 2019)
- holiday after Connect
Current Review Queue
====================
* {RFC v2 00/38} Plugin support
Message-Id: <20181209193749.12277-1-cota(a)braap.org>
* {Qemu-devel} {PATCH 00/23} tests/tcg/xtensa: conditionalize xtensa tests
Message-Id: <20190219061111.10231-1-jcmvbkbc(a)gmail.com>
* {PATCH 00/10} Rework debug exception handling code
Message-Id: <20190301132809.24653-7-will.deacon(a)arm.com>
* {PATCH v2 00/11} Enable build and install of our rST docs
Message-Id: <20190228145624.24885-1-peter.maydell(a)linaro.org>
* {PATCH+RFC 0/6} target/arm: Define cortex-a{73,75,76}
Message-Id: <20190223023957.18865-1-richard.henderson(a)linaro.org>
* {PATCH v3 00/20} Acceptance Tests: target architecture support
Message-Id: <20190221005753.27955-1-crosa(a)redhat.com>
--
Alex Bennée
== Progress ==
* [Thumb GlobalISel] Support global variables [LLVM-540]
- Committed upstream
* [Thumb GlobalISel] Support G_CTLZ [LLVM-543]
- Committed upstream
- We now have the same level of support for Thumb2 and ARM mode
* LLVM 8.0.0 Release for ARM & AArch64 [LLVM-526]
- Tested and uploaded rc3
== Plan ==
* Out of office between 4 - 8 March (i.e. next week)
* GlobalISel bugfixing and cleanup (both ARM and Thumb2)
== Progress ==
* PR88836
- I have a patch (for backend and CSE) which now passes bootstrap and
regression except for one testcase failure (which looks like a pattern
issue). Looking into it.
* Look at GDB BZ #21221 - gdb hangs while stepping an empty loop
- Not convinced that it is a gcc issue. Looking into the dwarf specification.
* PR88838
- Looking at it.
- Also familiarising with auto-vectorisation of SVE
== Plan ==
* Complete above PRs
* Look at GDB BZ #21221 - gdb hangs while stepping an empty loop
[LLVM-158] Monitor and maintain buildbots
- Some work to track down a faulty msan test on AArch64 that was
intermittently failing.
- Spent some time trying to reproduce an intermittent failure in libfuzzer.
[LLVM-523] Synthesise EXIDX_CANTUNWIND entries for sections without tables.
- Not getting much response from upstream beyond a vague suggestion to
rewrite the whole of .ARM.exidx handling as a single custom section. I
may have to go down this path to get the feature accepted, even if it
is to show that it is a bad idea.
[LLVM-496] LLD in linux kernel
- Submitted patch to ignore -p (--no-pipeline-knowledge) which is used
by the AArch32 linux kernel.
- Submitted patch to integrate LLD in TCWG kernel regression test.
- Learned, the hard way, about how the linux kernel build system works
and how to pass extra flags.
Reviews:
Spent an awful long time looking at how clang passes options to GNU as
to try and match the existing clang defaults. I'm not sure I've seen
anything much more confusing than tracing through target features from
clang to llvm and back again.
re-essayer de flash le kernel sur la board (mais est-ce possible vu
qu'il semble plus gros que la flash?)
$ openocd -f /usr/share/openocd/scripts/board/stm32f429discovery.cfg
-f flash-kernel.cfg
[...]
Info : device id = 0x20016419
Info : flash size = 2048kbytes
Info : Dual Bank 2048 kiB STM32F42x/43x/469/479 found
Warn : no flash bank found for address 0
wrote 0 bytes from file
/home/lyon/src/kernel/linux/arch/arm/boot/xipImage in 0.007352s (0.000
KiB/s)
** Programming Finished **
demander de l'aide aux gens de ST?
re-essayer avec un openocd plus recent
== Progress ==
* FDPIC
- (GNU-411) GDB: debugging problems with FDPIC support. Trying to
setup a stm32 board to avoid problems with unsupported configurations
mix between kernel and qemu.
* GCC upstream validation:
- reported a few regressions
* GCC:
- (GNU-99) ubsan / bare-metal. No progress.
* misc (conf-calls, meetings, emails, ....)
- reviewing infra script patches
- debugging new benchmarking round-robin jobs
== Next ==
Holidays, back on March 4th
== Next-next ==
FDPIC:
- GCC: handle feedback on v4 patches
- GDB: update patches
- uclibc-ng: look at how to test fdpic mode with openadk
- complete board setup
Infra:
- benchmarking jobs
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ patch review: RTH's JSConv/FHM patchset
+ sent another arm pull request
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ Implemented and wired up the SSE-200 Message Handling Units
+ Implemented the mechanism by which a guest can power up CPU 1
+ Sent out patches for these; this can run the Zephyr MHU/dualcore testcase
+ Started looking at implementing floating point support for M profile
thanks
-- PMM
== Progress ==
* [Thumb GlobalISel] Support control flow [LLVM-530]
- Committed upstream
* [Thumb GlobalISel] Support accessing the stack [LLVM-527]
- Committed upstream
* [Thumb GlobalISel] Support floating point [LLVM-531]
- Committed upstream
* LLVM 8.0.0 Release for ARM & AArch64 [LLVM-526]
- Investigated the release blocker from rc1, turned out to be an
issue with the filesystem used in the container on the APMs
- Changed the release job to run on the D05 instead, where we use a
different container [LLVM-539]
- Testing still in progress
== Plan ==
* [Thumb GlobalISel] Support global variables [LLVM-540]
* Out of office between 4 - 8 March
