hi all,considering the big progress achieved in coresight drivers, perf, as well as opencsd, the prerequisites for making a move towards developing branch tracing in gdb for arm processors, based on etm are now available. Therefore I am publishing this request for comment, and looking forward for your feedback on this proposal.
Non intrusive execution recording for GDB using ARM CoreSight
Status of this Memo
This memo provides information for Linaro coresight and toolchain communities. Distribution of this memo is unlimited.
Abstract
A method of realizing execution recording in GDB in a non-intrusive way. This method is based on the use of CoreSight hardware tracing, available on ARM Cortex devices.
Table of Contents
1 Introduction 2 State of the art 3 Use cases 3.1 Self hosted debug monitor 3.2 Remote debug monitor 3.3 External debugger 4 Implementation needs 4.1 Self hosted debug monitor 4.2 Remote Debug monitor 4.3 External debugger 5 Remote protocol execution sequence 6 Remote protocol extensions 7 Solutions and alternatives 7.1 Scope definition 7.2 CoreSight infrastructure exposure to the user 7.3 Parameters needed for parsing traces
1. Introduction
CoreSight technology offers a toolset for tracing the execution of a program on a CPU, as well as routing the traces to an external trace port analyzer or storing it in a dedicated internal memory. Those traces do not affects system performance, and can be used as a record for program execution. GDB offers reverse debugging by recording program execution and storing it. GDB offers either full record or program flow (branch) record. Records can be replayed later-on for forwards or backwards debugging. This request for comments is about realizing GDB record and replay functionality using CoreSight technology. it presents typical use cases and discuss different alternatives for realizing above mentioned feature. 2. State of the art
GDB currently supports two execution recording variants: - full record: where registers as well as memory are recorded for each instruction. in this case GDB collects the registers as well as involved memory area after each instruction. currently this has no support for hardware accelerators - branch record: where only program flow is recorded. in this case GDB collects a list of linear execution called blocks. each branch will terminate previous block and start a new one. currently branch is implemented either without hardware acceleration or using Intel branch trace store "bts" and Intel processor trace "pt" hardware accelerator on supported cpus.
3. Use cases
Programs running on ARM processors can be be debugged in many configurations. three of them are selected in this RFC as base for discussion : 3.1. Self hosted debug monitor Those are systems where the debugger program runs on the same cpu as the debugged program and monitors it. user interacts with the debugging session on the target host itself. Linux gdb is an example of such systems. in such a system following setup is considered - Target: a process running on an ARM cortex A - Debugger: gnu gdb via ptrace API (arm-linux-gnueabihf-gdb)
+-----------------------------------+ | Target | | +------------+ | | +------+ | Coresight | | | | | | components:| | | | GDB |<--------->| | | | | | ^ | DWT, ETM, | | | +------+ | | ITM, TPIU | | | ^ | | TMC, ETB | | | | | +------------+ | +----|---------|--------------------+ | | | | arm-linux- | gnueabihf- | gdb | debug: ptrace trace: perf/CoreSight drivers
3.2. Remote debug monitor
Those are usually systems where the debugger program runs on the same cpu as the debugged program and monitors it. user interacts with the debugging session remotely from a PC Linux gdb is an example of such systems. in such a system following setup is considered - Target: a process running on an ARM cortex A - Gdb server: gnu gdbserver (arm-linux-gnueabihf-gdbserver) - Gdb client: gnu gdb (arm-linux-gnueabihf-gdb) - UI: eclipse with needed plugins, MI interface is used.
+--------------------------+ +---------------------------------------+ | Host | | Target | | | | +------------+ | | +-----+ +------+ | | +------+ | Coresight | | | | | | GDB | | | | GDB | | components:| | | | UI |<--->| |<--->|<--->|<--->| |<--------->| | | | | | ^ |Client| ^ | ^ | |Server| ^ | DWT, ETM, | | | +-----+ | +------+ | | | | +------+ | | ITM, TPIU | | | ^ | ^ | | | | ^ | | TMC, ETB | | | | | | | | | | | | +------------+ | +----|-----|-----|------|--+ | +--------|---------|--------------------+ | | | | | | | | | | | | | | Eclipse | arm-linux- | | arm-linux- | | gnueabihf- | TCP/IP gnueabihf- | | gdb | UART gdbserver | GDB MI GDB remote debug: ptrace protocol trace: perf/CoreSight drivers
3.3. External debugger
Those are systems where an external debugger is used. It accesses the target using JTAG or SWD. Target is usually a bare metal embedded systems or systems with an rtos. as an example, following setup is considered: - Target: firmware running on ARM cortex M. - Debugger: external debug and trace device. - Gdb server: OpenOcd. - Gdb Client: arm-none-eabi-gdb. - UI: eclipse with needed plugins, MI interface is used.
+--------------------------------------+ +-------+ +-------------+ | Host | | dbggr | | Target | | | | | | | | +-----+ +------+ +------+ | | | | Coresight | | | | | GDB | | GDB | | | Debug | | components: | | | UI |<--->| |<--->| |<-->|<--->| + |<--->| | | | | ^ |Client| ^ |Server| | ^ | Trace | ^ | DWT, ETM, | | +-----+ | +------+ | +------+ | | | | | | ITM, TPIU | | ^ | ^ | ^ | | | | | | | | | | | | | | | | | | | | +----|-----|-----|------|-----|--------+ | +-------+ | +-------------+ | | | | | | | | | | | | | | Eclipse | arm-none- | OpenOcd | | | eabi-gdb | PyOcd | | | | | | GDB MI GDB remote Ethernet debug: JTAG/SWD protocol USB trace: Serial/Parallel
4. Implementation needs
4.1 Self hosted debug monitor
gdb : arm-linux-gnueabihf-gdb the interface defined in btrace.h for capturing and processing traces has to be implemented for arm CoreSight needed actions: - in btrace-common.h: add needed structures for capturing and handling etm traces - in linux-btrace.h: - add btrace_tinfo_etm - amend btrace_target_info - in linux-btrace.c: change following functions to support etm traces - linux_enable_btrace - linux_disable_btrace - linux_read_btrace - linux_btrace_conf - in arm-linux-nat.c:add an api to - configure btrace - enable btrace - disable btrace - read btrace - in btrace.c - btrace_add_pc btrace_fetch has to be implemented for Coresight this means using opencsd library to parse etms and then reconstruct executed instructions accordingly (btrace_compute_ftrace_1) - in record-btrace.c - add command for showing record btrace etm options - add command for starting tracing with CoreSight and its handler (cmd_record_btrace_etm_start) - adapt cmd_show_record_btrace_cpu ... perf: needed actions: - make sure that perf can start/stop tracing a process with its threads, collect etm traces and deliver them to the user
4.2 Remote Debug monitor
changes described in 7.1 are needed. in addition, and to support remote protocol following changes are needed gdb server: arm-linux-gnueabihf-gdbserver needed actions: - in linux-low - linux_low_read_btrace: add support for etm traces formatting. - linux_low_btrace_conf: :add support for etm configuration formatting. gdb client: arm-linux-gnueabihf-gdb needed actions: - in remote.c - adapt enable_btrace - adapt disable_btrace - in btrace.c - parse_xml_btrace: update btrace.dtd [2] and related data structures btrace_xxx - parse_xml_btrace_conf: update btrace-conf.dtd [3] and related data structures btrace_conf_xxx - extend Remote protocol handling to support coresight etm traces UI: eclipse needed actions make sure that the plugin for recoding execution and replaying it is coping well in case of arm-linux
Remote protocol needs to be extended by -1- Adding Qbtrace:CoreSight (or etm) to start collecting etm traces -2- Amending 'Branch Trace Format' xml specification to consider etm traces transfer -3- Amending 'Branch Trace Configuration Format' xml specification to consider parameters needed for etm
4.3 External debugger
changes described in 4.2 are needed. in addition, and to support tracing a remote dealing with an external debugger (bare metal embedded system) following changes are needed gdb server: OpenOcd needed actions: - rework etm driver to make it up to date. - add a driver for configuring trace interconnect IPs - rework the driver for TPIU. - integrate support for a Trace port analyzer. -Extend remote protocol implementation to support recording Coresight infrastructure of the SoC is to be set in OpenOcd through configuration files. Parameters that are not relevant for gdb are also specified in configuration files (trace sink, trace protocol, port size, trace synch frequency, cycle accurate tracing etc ...) gdb client: arm-none-eabi-gdb needed actions: - extend Remote protocol to support coresight etm traces - integrate etm trace parsing library - interface the parser to record_btrace_target Remote protocol needs -in addition to 4.2- to be extended by - Adding Qbtrace-conf:CoreSight:core=value to support multicore SoC - Adding btrace-conf:CoreSight:id=value to support demultiplexing multiple trace sources - Adding Qbtrace-conf:CoreSight:filter:context=value to support filtering traces belonging to a given process/thread - Adding Qbtrace-conf:CoreSight:filter:start-address=value and Qbtrace-conf:CoreSight:filter:end-address=value to support filtering traces for given functions/blocks/lib - Adding Qbtrace-conf:CoreSight:trigger:on-address=value and Qbtrace-conf:CoreSight:trigger:off-address=value to support triggering tracing or stop tracing if a certain function/block/lib is executed alternatively some of configurations related to filtering and triggering can be delegated to the GDB server. UI: eclipse test and verify that existing plugins cope well with gdb extensions
5. Remote protocol execution sequence
gdb and gdbserver are communicating using the gdb remote protocol. on a semantic level a tracing session runs though following sequence (1) gdb client queries gdb server support for branch trace (2) gdb server answers with - qXfer:btrace:read - qXfer:btrace-conf:read - Qbtrace:off - Qbtrace:CoreSight - Qbtrace-conf:CoreSight:xxx where xxx is the parameter name (3) gdb client sends command to let start emitting and collecting traces (Qbtrace:CoreSight) (4) gdb server executes the commands (5) gdb client sends command to stop emitting and collecting traces (Qbtrace:off) (6) gdb server exectues the command (7) gdb client sends command to get collected traces from trace sink (qXfer:btrace:read:annex:offset,length) (8) gdb server executes the command and sends back collected traces (9) gdb client parses the traces and reconstructs target states
6. Remote protocol extensions
the remote protocol needs be extended with following primitives to support CoreSight tracing - start tracing and traces capture using CoreSight (Qbtrace:CoreSight) the remote protocol can be extended with following primitives to take advantages of etm functionalities. - select the core to trace on in the case of a multicore system gdb client sends command to select the core to trace (Qbtrace-conf:CoreSight:core=value) - set the trace id for the traces gdb client sends command to set trace id (Qbtrace-conf:CoreSight:id=value) - select the context to trace gdb client sends command to select the context to trace (Qbtrace-conf:CoreSight:filter:context=value) - select the address range to trace gdb client sends command to select the address range to trace (Qbtrace-conf:CoreSight:filter:start-address=value) (Qbtrace-conf:CoreSight:filter:end-address=value) - set triggers for starting and stopping tracing gdb client sends command to select the address to trigger tracing (Qbtrace-conf:CoreSight:trigger:on-address=value) (Qbtrace-conf:CoreSight:trigger:off-address=value)
7. alternatives and discussions
7.1. Scope definition
Coresight ETM IP comes in many versions and many implementations. According to its capabilities, it can trace instructions only or instructions and involved data/data address. All ETMs variants support instructions tracing and can therefore be used for for branch tracing.
7.2. CoreSight infrastructure exposure to the user
it is here about assigning the responsibility of configuring Coresight infrastructure to generate and route traces. two alternatives are possible: - coresight infrastructure exposed to gdb client (and UI): in this alternative the user or the UI is responsible for configuring coresight IPs in the SoC, by accessing their registers directly or via coresigh driver. Remote protocol is used to configure trace sink (ETB or TPA) to start/stop collecting traces - coresight infrastructure is not exposed outside of gdbserver. in this case high level commands can be provided by gdbserver remote protocol to setup and configure coresight IPs in the SoC. My recommendation is to extend remote protocol to provide high level commands to setup and configure coresight IPs in the SoC, or to use a different channel to pass configuration parameters to gdb server
7.3. parameters needed for parsing traces Some configuration parameters like etm version, trace id ... (content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR) are needed for extracting and parsing etm trace, those parameters needs to be exchanged between gdb server and client. following alternatives are possible: - extend the remote protocol to get those params with explicit queries - add them to the content of the response to qXfer:btrace-conf:read - add them to the content of the response to qXfer:btrace:read
Best RegardsZied Guermazi
o LLVM
* Machine outliner:
- Rebased on upstream.
- Improved stack alignment handling
- More cleanup before submission
o Misc
* Various meetings and discussions.
[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ]
Posted v6. Some review from Dave Martin; will need at least
one further revision, and to wait til the kernel patches land.
[VIRT-327 # Richard's upstream QEMU work ]
Fix a reported bug in pauth Auth results.
Fix a reported bug in vector variable shift.
Review Peter's vfp decodetree patch set.
Review of v18 of target/rx. Never-ending, it seems...
Review of some target/ppc vector patches.
Posted v4 of CPUNegativeOffsetState. This looks ready to pull.
r~
Upstream Work ([VIRT-109])
==========================
- spent ages tracking down 64-on-32 cputlb errors which led to:
- adding x86_64 support to TCG system tests
- {PATCH v1 0/4} softmmu de-macro fix with tests Message-Id:
<20190605162326.13896-1-alex.bennee(a)linaro.org>
- {PATCH} cputlb: cast size_t to target_ulong before using for
address masks Message-Id:
<20190606154310.15830-1-alex.bennee(a)linaro.org>
- took over maintainership of orphaned gdbstub
- posted {PULL 00/52} testing, gdbstub and cputlb fixes Message-Id:
<20190607090552.12434-1-alex.bennee(a)linaro.org>
- problems on hackbox lead to {PATCH} tests/vm: favour the locally
built QEMU for bootstrapping Message-Id:
<20190607185337.14524-1-alex.bennee(a)linaro.org>
[VIRT-109] https://projects.linaro.org/browse/VIRT-109
Other Tasks
===========
- Did some initial reading on RPMB
- Half day fire training
Absences
========
- May 27th is a Bank Holiday
- May 31st working on train in the afternoon
Current Review Queue
====================
* {Qemu-devel} {PATCH v4 00/39} tcg: Move the softmmu tlb to CPUNegativeOffsetState
Message-Id: <20190604203351.27778-1-richard.henderson(a)linaro.org>
* {Qemu-devel} {PATCH v2} target/arm: Vectorize USHL and SSHL
Message-Id: <20190603232209.20704-1-richard.henderson(a)linaro.org>
* {Qemu-devel} {PATCH resend} test-thread-pool: be more reliable
Message-Id: <20190530093417.23370-1-pbonzini(a)redhat.com>
* {PATCH 0/4} tests/docker: add podman support
Message-Id: <20190523234011.583-1-marcandre.lureau(a)redhat.com>
* {Qemu-devel} {PATCH 0/2} Implement PowerPC FPSCR flag Fraction Rounded
Message-Id: <20190525022008.24788-1-programmingkidx(a)gmail.com>
* {Qemu-devel} {PATCH for-4.1 v2 00/36} tcg: Move the softmmu tlb to CPUNegativeOffsetState
Message-Id: <20190328230404.12909-1-richard.henderson(a)linaro.org>
--
Alex Bennée
[LLVM-122] BTI and PAC support
Committed the LLD work. Modulo bugs this should now be done.
[LLVM-542] LLVM/GCC code size investigation
- Revisited my Zephy build with clang patches and updated so that it
works with trunk.
- Work out next steps of work.
- Work out to build an embedded gcc toolchain using the linaro infrastructure.
[Misc]
Reported bug in gold whereupon it would generate v4t veneers for v8-a CPUs
Still waiting for TK-1 board to finish building clang so that it can
run the testsuite. Hopefully finished over the weekend.
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ Got the VFP decodetree conversion patchset out for review
(42 patches, 8 files changed, 3024 insertions(+), 1476 deletions(-))
+ sent a patchset which does the (easy) first step in my plan
for converting QEMU's documentation to Sphinx; sadly all the other
steps are much trickier...
thanks
-- PMM
== Progress ==
* FDPIC
- GCC: No progress, still waiting for feedback
* GCC upstream validation:
- reported a few regressions.
* GCC:
- UBSAN/bare-metal: added sync primitives implementation for low-end
cores (eg cortex-m0) Seems OK
- noinit attribute: started work
* Infra
- Fixed Dejagnu configuration issue in ABE which prevented us from
using target variant specifications
- Investigated problems with ABE and failure to cross-build "recent"
glibc (trouble with C++ compiler detection). ABE patches under review.
- Reduced load on APM machines to avoid depending on them too much
== Next ==
GCC:
- handle feedback on FDPIC patches
- noinit attribute
- UBSAN/bare-metal: do more testing
Hi,
Food for thought for today's sync up. I've been writting QEMU plugins to
exercise the plugin system and see what sort of useful information you
can extract when you can control the instruction stream.
For example I now have a plugin that can break down instruction counts
for any given run, for example a kernel boot:
Instruction Classes:
Class: UDEF not counted
Class: SVE (68 hits)
Class: Reserved (0 hits)
Class: PCrel addr (4589078 hits)
Class: Add/Sub (imm,tags) (0 hits)
Class: Add/Sub (imm) (26832113 hits)
Class: Logical (imm) (74304974 hits)
Class: Move Wide (imm) (10933759 hits)
Class: Bitfield (71470957 hits)
Class: Extract (85655 hits)
Class: Data Proc Imm (0 hits)
Class: Cond Branch (imm) (37227632 hits)
Class: Exception Gen (6 hits)
Class: NOP not counted
Class: Hints (244825554 hits)
Class: Barriers (1668558 hits)
Class: PSTATE (202144 hits)
Class: System Insn (7132992 hits)
Class: System Reg (2268308 hits)
Class: Branch (reg) (6280976 hits)
Class: Branch (imm) (18347905 hits)
Class: Cmp & Branch (180167025 hits)
Class: Tst & Branch (4092972 hits)
Class: Branches (0 hits)
Class: AdvSimd ldstmult (0 hits)
Class: AdvSimd ldstmult++ (0 hits)
Class: AdvSimd ldst (0 hits)
Class: AdvSimd ldst++ (0 hits)
Class: ldst excl (160861365 hits)
Class: Prefetch (0 hits)
Class: Load Reg (lit) (12828544 hits)
Class: ldst noalloc pair (0 hits)
Class: ldst pair (60381349 hits)
Class: ldst reg (0 hits)
Class: Atomic ldst (0 hits)
Class: ldst reg (reg off) (0 hits)
Class: ldst reg (pac) (0 hits)
Class: ldst reg (imm) (119597941 hits)
Class: Loads & Stores (0 hits)
Class: Data Proc Reg (113586343 hits)
Class: Scalar FP (0 hits)
Class: Unclassified (0 hits)
You can break down each class to individual instructions. For example
the Hints are mostly:
Individual Instructions:
Instr: wfe (132400072 hits) (op=0xd503205f/ Hints)
Instr: sevl (66433640 hits) (op=0xd50320bf/ Hints)
Instr: yield (29619246 hits) (op=0xd503203f/ Hints)
Instr: wfi (2865 hits) (op=0xd503207f/ Hints)
So I'm looking for a similar experiment that would be useful for the
memory sub-system. When I chatted to Maxim we thought maybe a simplified
cache line simulator might be useful. The aim wouldn't be to simulate
what a real cache might do but to be useful say for identifying regions
of code which might be susceptible to cache line bouncing. So as
compiler writers what sort of run time memory behaviour would you like
to track? What sort of information would be useful to extract with such
a tool?
I'm open to ideas ;-)
--
Alex Bennée
Four day week.
[VIRT-327 # Richard's upstream QEMU work ]
Reviewed s390 fp vector patch set.
Posted v16 rx. This seemed so close to being ready
last week, but now I don't know. I think I should
quit pushing it myself and let Yoshinori do more of
the lifting here.
Reviewed avr v20 patch set.
Reviewed Alex's testing patch set.
Submitted patches to constify upstream capstone
(500k from .data to .rodata).
r~
Short week (off Thursday/Friday)
== Progress ==
* FDPIC
- GCC: No progress, still waiting for feedback
* GCC upstream validation:
- reported a few regressions / fixed some testcases
* GCC:
- UBSAN/bare-metal: added sync primitives implementation for low-end
cores (eg cortex-m0) Seems OK
* Infra
- cleanup
- handling some problems with boards upgrades and crashes
== Next ==
FDPIC:
- GCC: handle feedback
UBSAN/bare-metal: do more testing
== This Week ==
* PR88837 (7/10)
- Addressed all upstream suggestions.
- Found a (hackish) way to test patch with qemu (multiple issues).
- Sorting thru "strange" testsuite fallout most of which seems
unrelated to my patch.
* PR88833 (2/10)
- Looking at fwprop pass
* Misc (1/10)
- Meetings
== Next Week ==
- Continue ongoing tasks.
(Short week, three days.)
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ continuing with the conversion of the VFP decoder to 'decodetree'.
With some useful advice from RTH I have now got a big chunk of
it done, and it looks like this will provide:
- better places to put "UNDEF if CPU doesn't have double support" checks
- checks of "VFP enabled?" only after all UNDEF checks have happened
- cleanup of a lot of code that uses some TCG globals cpu_F0 and cpu_F1,
which is weird ancient style and overdue for a cleanup
- a VFP decoder which isn't a single thousand-line function with multiple
nested switch statements
thanks
-- PMM
3 day week.
[LLVM-122] BTI and PAC support in lld, llvm-readobj, llvm-objdump
- Now in upstream review. Most of the week spent writing and updating tests.
Some time reviewing some asm goto patches patches.
Planned absences:
Holiday Friday 31st May.
== Progress ==
* Out of office 22 & 24 May
* [GlobalISel] Refactor CallLowering [LLVM-568]
- In progress, likely going to take a while
- Found a minor bug in the lowering for AArch64 (I can get it to
crash on some edge case), not sure if it's worth fixing independently
since it gets fixed anyway with the refactoring that I have in
progress
- Trying to understand an AMDGPU failure
== Plan ==
* Out of office 29 May - 10 June
* More of the same
o LLVM
* 8.0.1-rc1 ARM and AArch64 Binaries uploaded.
* Buildbots: One fixe committed upstream.
* Machine outliner:
- Fixed liveness issue.
- Preparing pat6ch for re-submission
o Misc
* Various meetings and discussions.
[VIRT-343 # ARMv8.5-RNG, Random Number Generator ]
Merged!
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
Started dusting off and rebasing wip.
[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ]
Started reviewing the kernel patch set for this feature.
[VIRT-327 # Richard's upstream QEMU work ]
PR for tcg gvec work.
PR for Sato-san's RX target.
Patch set to update capstone and enable s390x.
GSOC: Review v3 of Jan's enable risu for x86 patch set.
[Other]
Travel arrangements for Xilinx meeting in San Jose, June 13.
Will need to pick Peter's brain re m-profile before then.
r~
== This Week ==
* PR88833 (4/10)
- Started investigating the issue, it seems one of the code-movement
RTL passes like cse2
do not remove identical register copies resulting in extra register move.
* PR88837 (5/10)
- Patch almost approved offline by Richard, suggested me to move
discussion upstream.
- Observed "strange" issue with return value vectors on qemu for
run-time tests for fixed-length vectors. Turned out due to mismatch
in vector-length at compile and run time -;)
- Trying to run SVE tests with qemu.
* Misc (1/10)
- Meetings
== Next Week ==
- Continue ongoing tasks
[LLVM-122] BTI and PAC support in LLD
Implementation now working, have written BTI tests, next step is
finishing off PAC tests.
[Misc]
Helped out debugging an asm-goto problem on ARM targets.
Investigated a GNU ld LMA overlap when VMA and LMA got out of sync.
Helped out with CMSIS use of ld scripts when using a fast-model,
needed to get LMA == VMA for program header covering BSS.
QEMU Tooling ([VIRT-252])
=========================
QEMU plugin support ([VIRT-280])
- synced up with Emilio, will take over branch and submit
- latest branch is [plugins/plugins-v3]
- will peel off simple clean-ups and tweaks next week
- then need to split up some more and better separate code
- exposed plugin_disas to for "howvec" instruction counter
- some [example] [output] while booting kernel
[VIRT-280] https://projects.linaro.org/browse/VIRT-280
[plugins/plugins-v3]
https://github.com/stsquad/qemu/tree/plugins/plugins-v3
[example] http://ix.io/1JXC
[output] http://ix.io/1JXl
GSoC Mentoring ([VIRT-348])
- planning for start of coding next week
[VIRT-348] https://projects.linaro.org/browse/VIRT-384
Upstream Work ([VIRT-109])
==========================
- prepared [testing/next] for PR
[VIRT-109] https://projects.linaro.org/browse/VIRT-109
[testing/next] https://github.com/stsquad/qemu/tree/testing/next
Completed Reviews [3/3]
=======================
{RISU v3 00/11} Support for i386/x86_64 with vector extensions
Message-Id: <20190523204409.21068-1-jan.bobek(a)gmail.com>
{PATCH v10 00/20} gdbstub: Refactor command packets handler
Message-Id: <20190521095948.8204-1-arilou(a)gmail.com>
- CLOSING NOTE [2019-05-24 Fri 17:30]
awaiting re-spin with tags applied.
{RFC v2 00/38} Plugin support
Message-Id: <20181209193749.12277-1-cota(a)braap.org>
- CLOSING NOTE [2019-05-24 Fri 17:47]
taking over the tree
Absences
========
- May 27th is a Bank Holiday
- May 31st working on train in the afternoon
Current Review Queue
====================
* {PATCH 0/5} tests/vm: Python 3, improve image caching, and misc
Message-Id: <20190329210804.22121-1-wainersm(a)redhat.com>
* {Qemu-devel} {PATCH for-4.1 v2 00/36} tcg: Move the softmmu tlb to CPUNegativeOffsetState
Message-Id: <20190328230404.12909-1-richard.henderson(a)linaro.org>
* {Qemu-devel} {RFC v4 0/7} Baby steps towards saner headers
Message-Id: <20190523081538.2291-1-armbru(a)redhat.com>
* {Qemu-arm} {PATCH v2 0/4} hw/arm/boot: handle large Images more gracefully
Message-Id: <20190516144733.32399-1-peter.maydell(a)linaro.org>
* {Qemu-devel} {PATCH v12 00/12} Add RX archtecture support
Message-Id: <20190514061458.125225-1-ysato(a)users.sourceforge.jp>
* {PATCH 00/13} target/arm/kvm: enable SVE in guests
Message-Id: <20190512083624.8916-1-drjones(a)redhat.com>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ sent patchset fixing a handful of simple GICv3 bugs
+ usual codereview work
+ sent out a sketch of how we can transition our documentation
from the current texinfo manual to a set of sphinx manuals
+ had a look at the practicalities of converting our hand-written
VFP decoder to 'decodetree' -- this may be the easiest way to
support FPU configs which only support single-precision, like Cortex-M33
thanks
-- PMM
== Progress ==
* FDPIC
- GCC: Updated patch 03/21 with changes in the handling of -static
according to feedback. Pinged the whole series.
* GCC upstream validation:
- reported a couple of regressions
* Infra
- [stalled] working on adding binutils regression testing to round-robin jobs
- cleanup
- handling some problems with boards upgrades and crashes
== Next ==
FDPIC:
- GCC: handle feedback
UBSAN/bare-metal: look at how to make it easier to use on CPUs that
lack sync primivites (eg cortex-m0)
== This Week ==
* PR88837 (9/10)
- Tweaked patch to handle few more special cases with suggestions from
Richard.
* Misc (1/10)
- Meetings
== Next Week ==
- Continue ongoing tasks
o LLVM
* 8.0.1-rc1 Started Binaries build.
* Buildbots babysitting:
- Two fixes committed upstream
* Machine outliner:
- Liveness informations are not accurate after FrameLowering,
investigation on-going.
o Misc
* Various meetings and discussions.
[VIRT-343 # ARMv8.5-RNG, Random Number Generator ]
Posted v7 and v8. I think this is now ready for merge,
but I said that last week as well. :-P
[VIRT-327 # Richard's upstream QEMU work ]
More gvec work, some of which applies to target/arm,
and some to tcg/aarch64/, but all of which is in support
of David's target/s390x work. Should be coming to a
close on that soon.
Posted v7 of my do_syscall split.
Reviewed v13 of the RX target, adjusted it slightly for
my tlb_fill changes. I think this now ready to merge.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ finally managed to complete review of Damien's reset handling rework
+ rolled v2 of patchset to support booting large kernel images
+ sent a cleanup patchset to rename arm.h to boot.h
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ working on making the CPU model configurable without FPU or DSP,
so that we can correctly model the Musca-A and MPS2-AN521 boards as
not having FPU or DSP on CPU #0.
thanks
-- PMM
== Progress ==
* FDPIC
- GCC: sent updated patch series (v5). Received feedback about -static
support vs dynamic-linkker need. Discussing options.
* GCC upstream validation:
- reported a couple of regressions
- found a bug in qemu while testing v4.0.0, preparing a reproducer
* Infra
- [stalled] working on adding binutils regression testing to round-robin jobs
- cleanup
== Next ==
FDPIC:
- GCC: handle feedback
UBSAN/bare-metal: look at how to make it easier to use on CPUs that
lack sync primivites (eg cortex-m0)
== Progress ==
* [GlobalISel] Add support for integers > 32 bits wide [LLVM-310]
- While looking into this I found and fixed a bug in the generic
part of IRTranslator, which reduced the number of fallbacks on the ARM
test-suite by about 20%
- Currently working on lowering function calls etc for 64-bit types
* [GlobalISel] Refactor CallLowering [LLVM-568]
- The CallLowering interface really needs a cleanup before I
continue with LLVM-310
- This has been discussed upstream in the past and would benefit all
targets, so I'm going to give it a shot
* SVE2 code reviews
== Plan ==
* More of the same
* Out of office 29 May - 10 June
== Progress ==
* Out of office on Friday (sick)
* [GlobalISel] Better support for small types [LLVM-553]
- Committed upstream
* GlobalISel
- quickfix for a DBG_VALUE-related bug
- code reviews
* SVE code reviews
* Catching up on Connect / EuroLLVM
== Plan ==
* More of the same
* Out of office end of May - beginning of June
[VIRT-343 # ARMv8.5-RNG, Random Number Generator ]
Posted v4, v5, v6. I think this is now ready for merge.
[VIRT-327 # Richard's upstream QEMU work ]
Posted v3 of the CPUNegativeOffset patch set.
Posted v2, v3, and a pull request for the tlb_fill patch set.
Debugged one more fix for Sparc testthreads.
Reposted some long dormant linux-user fixes.
Started reviving the do_syscall split patch set,
since Laurent asked after it.
r~
o 4 days week.
o LLVM
* Machine outliner:
- Fixed LR save issue, when saved into a register.
- Dealing with LR save/restore when outlined region is a
pop{...,PC} tail-call.
- Investigating potential issue with condition flags.
o Misc
* Various meetings and discussions.
[LLVM-158] buildbot maintenance
- Increased timeouts on some libfuzzer tests, aarch64 full bots should
fail less frequently under load.
[LLVM-534] -n -N support in LLD (needed for Linux kernel allyesconfig
CI with LLD on AArch64)
Rewrote using a different approach after upstream comments
[LLVM-122] BTI and PAC support in LLD
Wrote an implementation, it compiles, but completely untested as of today.
(short week: 3 days)
Brief writeup of a pair of talks I attended on Tuesday at the
Cambridge University Computer Lab by some people from Amazon:
Diana Popa talked about Amazon's new "Firecracker" VMM (virtual
machine monitor -- the userspace component that uses the kernel's KVM
APIs to create and control virtual machines; kvmtool and QEMU are both
VMMs). Their use case is the AWS Lambda service, where VMs are
generally fairly short-lived (on the order of hours), startup time
matters a lot, and the VMs typically don't need very much CPU/RAM
resource. Firecracker is written in Rust, and provides a very simple
guest device model (virtio block and network devices), booting a
kernel that knows it is virtualized. It boots the kernel directly,
without running a BIOS. It has a memory footprint of less than 5MB and
a boot time of 125ms. They are currently working on Arm support (they
have it booting, but some bits still need work, eg the VM doesn't get
the right time because there is no RTC device exposed to the guest).
My feeling was that this shows an advantage of the KVM design: the
kernel/userspace split makes it easy to replace the userspace VMM
part with something customised for the task at hand if you don't
need a full-fat all-bells-and-whistles general-purpose solution.
Andreea Florescu talked next, about the "rust-vmm" libraries. This is
a set of open-source Rust crates which are intended to abstract out
some of the common building blocks for VMMs. Firecracker started as a
fork of Google's crosvm project, but since the use-case requirements
for the two projects are markedly different the code diverged fairly
rapidly. rust-vmm is intended to allow the projects to share code for
things like "nice Rust interfaces to the KVM ioctls" and
"implementations of virtio devices". The project is still in quite an
early stage of development -- they have a few crates that have made it
to the "stable, published on crates.io" phase, but most are either in
"being developed" or still just "planned/proposed/discussed". It's
currently Apache-2.0 licensed, but they are planning to dual-license
to Apache-2.0 | 3-BSD because Apache-2.0 isn't GPL-2.0 compatible, and
they have had some interest in being able to experiment with using
these crates with QEMU. (That sounds a bit outlandish but it's
actually something I'm planning to look into myself -- the nice thing
about Rust is that you can potentially incrementally add it to an
existing C codebase without requiring a ground-up rewrite, so allowing
security hardening of the more "risky" parts. This is very definitely
all still just "exploratory prototyping" though.)
Progress:
* just miscellaneous upstream stuff
thanks
-- PMM
* 1 day off (public holiday)
== Progress ==
* FDPIC
- rebased GCC FDPIC patches. Fixing conflict with fstack-protector.
* GCC upstream validation:
- Fixed ST internal validation broken since GCC bumped to version 10.
Still some spurious failures probably caused by NFS. Testing
workarounds.
- reported a couple of regressions
* GCC
- ubsan on bare-metal toolchain: no news.
* Infra
- [stalled] working on adding binutils regression testing to round-robin jobs
== Next ==
FDPIC:
- GCC: fix problems with fstack-protector
UBSAN/bare-metal: look at how to make it easier to use on CPUs that
lack sync primivites (eg cortex-m0)
o 4 days week.
o LLVM
* Machine outliner:
- Identified an issue related to LR saving inside an outlined
chunk, working on a proper fix.
o Misc
* Various meetings and discussions.
[VIRT-327 # Richard's upstream QEMU work ]
Review Mark's target/ppc getVSR patch set.
Two rounds of "tcg vector improvments"; hopefully that's
ready to go in on Monday.
More work on "bit select" and "compare select" primitives.
I can now vectorize Neon VSHL/VSHR variable shift (where
positive values are left shift and negative values are
right shift). Waiting on posting this while previous tcg
vector patch set is still in flight.
Review Alex's demacrofy v5. Wrote a boot.S for Alpha.
Review David's latest target/s390 vector patch set.
Review Sato-san's target/rx v8. Played around with a few
disassembler improvements, but I'll not confuse the review
process by posting them now.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ pushed QEMU 4.0 out the door
+ code review:
- RTH's patchset that cleans up the softmmu TLB structs
- Nios2 nommu and semihosting patchset from codesourcery
- cleanup series removing a "bucket of random stuff" header file
- RTH's patchset adding BTI support for linux-user mode
- RTH's patchset cleaning up the tlb_fill API
- RTH's patchset implementing Cortex-A73, A75, A76
- "SBSA reference platform" new board model
- patchset adding Netduino Plus 2 board model
- linux-user patch to correctly handle loading ELF segments which
have no file data (ie only bss)
- patch adding the RTC device to the ASpeed board models
- patchset fixing various minor problems preventing QEMU building
cleanly for Windows-on-Arm
- started looking at Damian's patchset that overhauls how we do
device reset; this is good work that's long overdue, but reviewing
it requires me to wrap my head around the problem space...
+ sent out v2 versions of a few minor patches that needed respins
+ wrote email to qemu-devel asking for volunteers to help with
QEMU release work so it's not only me doing this every cycle
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ FPU support now upstream
+ a few loose ends remain to be tidied up, but this epic is
now essentially complete
NB: out of office Tues 7th afternoon to attend a couple of lectures
at the CL by people from Amazon on their virtualization stack written
in Rust (http://talks.cam.ac.uk/talk/index/119491 and
http://talks.cam.ac.uk/talk/index/121069)
thanks
-- PMM
[LLVM-158] Buildbot monitoring duty
- Reported bug that libc++ when built as part as libfuzzer is not
built with PIC or PIE, yet some tests for non-x86 force PIE which then
fails at link-time.
- Reported bugs in libstdc++ and clang where exception specifications
didn't match due to extra parentheses. libstdc++ now fixed to not have
any discrepancy, clang bug for not ignoring the extra parentheses
still active.
- Investigated libfuzzer intermittent failures, 2 look like timeouts
not being long enough, submitted patch to get this increased.
[LLVM-122] BTI/PAC Started prototyping an implementation based on top
of the yet to land LLD patch for Intel CET.
Think about how to add crypto extensions without overriding
architecture in a complex build system.
Review comments for LLD and compiler-rt, and mailing list proposal for
something similar to __attribute__((at(address))).
* 1 day off (public holiday)
== Progress ==
* FDPIC
- Looked at gdbserver memory consumption increased since release 7.5.
Found similar results to Prathamesh. On arm-linux-gnueabihf with a
sample test program, gdbserver memory usage increased from ~500kB to
~1.5MB. But that should not prevent execution on board (which has
16MB); maybe memory fragmentation?
- rebased GCC FDPIC patches. There's a regression since Thomas
committed fixes to fstack-protector.
* GCC upstream validation:
- ST internal validation broken since GCC bumped to version 10. I was
using an old glibc. Upgrading glibc proved to be painful (requiring
new versions of make, bison, python....). Still using RH6 servers.
* GCC
- ubsan on bare-metal toolchain: Sent an email to llvm-dev list,
requesting help in how-to-cross-build runtime libs in clang/llvm. No
response so far....
* Infra
- [stalled] working on adding binutils regression testing to round-robin jobs
- fixed legacy binutils regression testing by switching to new slaves
- sent patches to support new slave (tcwg-lc-01)
- sent ABE patches to support new gcc9 config, and update to latest-rel config
== Next ==
FDPIC:
- GCC: fix problems with fstack-protector
UBSAN/bare-metal: look at how to make it easier to use on CPUs that
lack sync primivites (eg cortex-m0)
Infra:
- Fix ST internal validation
== Progress ==
* Out of office 1 day (public holiday)
* [GlobalISel] Better support for small types [LLVM-553]
- Fixed the bug that I'd been looking into
- Committed support for several instructions, only 3 left to commit next week
* IR SVE Reviews [LLVM-545]
- Looked into the patches for stack management
* GlobalISel code review
- Currently looking into an unpleasant patch adding a new opcode
* Catching up on Connect / EuroLLVM
== Plan ==
* More of the same
* Out of office end of May - beginning of June
[VIRT-327 # Richard's upstream QEMU work ]
Another round on launchpad 1824853, TB overflow.
This time handling relocation overflow. Which would
not be seen on an x86 host (2GB displacement), but
would affect some of the risc hosts.
Reviewed Peter's v7m fpu patches.
Another round on util/path.c, fixing the startup loop
that we get into for using a full chroot for -L.
Poked my nose into Alex's cputlb demacrofy patch set.
Hopefully the feedback was helpful...
First two pull requests for 4.1.
r~
[PR40542] Sent patch for -n and -N support in LLD for upstream review
[LTO]
Investigated problems when using -Os -Oz with LTO, raised 2 PRs
- error if clang linker invocation uses -Os and -Oz
- strange error message when .bc used as a file extension for a
separate compile and link step
Crash in GNU ld when linking LLVM lto via the gold plugin. Looks like
a memory access/corruption problem in the conversion from .bc to bfd.
Other miscellaneous reviews for some linker script support in LLD.
Investigation into why ld.bfd with NOLOAD on the .gnu.build-id section
corrupts debug information.
== This Week ==
* PR88837 (7/10)
- Discussed and finalized algorithm for vector construction with Richard.
* GNU-606 (1/10)
- Experimented gdbserver memory consumption with docker.
* Public Holiday (2/10)
== Next Week ==
- Continue ongoing tasks.
== Progress ==
* Short week (Out of office 22 - 24 April)
* [GlobalISel] Better support for small types [LLVM-553]
- Investigated my bug some more, it doesn't seem to be related to my
recent patches but rather an existing issue which is exposed because
we select more functions now
- Might be related to LLVM-456 (Fix frame index sizes for i<32)
* Catching up on Connect / EuroLLVM
== Plan ==
* Try to confirm root cause of LLVM-553 issue
[VIRT-327 # Richard's upstream QEMU work ]
Fix TranslationBlock overflow, launchpad 1824853.
Investigated launchpad 1824768, i386 emulation on arm32.
But works-for-me.
A bunch of work on new gvec primitives. Primarily to
support David Hildebrand's target/s390 conversion, but
it does enable more vectorization in target/arm as well.
r~
== Progress ==
* FDPIC
- Troubleshooting with stm32f469-disco. Trouble connecting via
cross-gdb over openocd. Updated GNU-411 and discussing with Omair.
Created GNU-606 to investigate if gdbserver memory consumption
increased since release 7.5.
* GCC upstream validation:
- little activity this week, close to e/o stage 4
* GCC
- ubsan on bare-metal toolchain: discussed with Peter, I will send an
email to llvm-dev list.
* Infra
- several boards crashed, increasing Jenkins build queue
- working on adding binutils regression testing to round-robin jobs
== Next ==
More of the on-going tasks
== Progress ==
* Short week (Out of office 18 - 19 April)
* LLVM 7.1.0 Release for ARM & AArch64 [LLVM-546]
- Uploaded binaries for both ARM & AArch64
* [GlobalISel] Better support for small types [LLVM-553]
- Still in progress (currently investigating a bug)
* Catching up on Connect
== Plan ==
* Back at work on Thursday, April 25th
Progress: (very short week, 2 days)
* VIRT-65 [QEMU upstream maintainership]
+ QEMU release work: flurry of last minute stuff for rc3. I hoped
we would not need an rc4, but as usual a release-critical issue
was found, so we will be having one.
+ code review
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ worked through some final bug fixes
+ sent out v1 of the FP support patchset for review
thanks
-- PMM
(Previous week was Connect.)
Progress: (short week, 3 days)
* VIRT-65 [QEMU upstream maintainership]
+ QEMU release work: flurry of last minute stuff for rc3.
I hoped we would not need an rc4, but as usual a release-critical
issue was found, so we will be having one.
+ code review
thanks
-- PMM
== Progress ==
* FDPIC
- Experimenting with stm32f469-disco. It seems recent gdbserver is now
too large to load (issues when trying to map libstdc++.so while
attempting to load a simple hello.c)
* GCC upstream validation:
- little activity this week, close to e/o stage 4
* GCC
- ubsan on bare-metal toolchain: experimenting with multlibs
* Infra
- improved reporting of some jobs, improved error handling
== Next ==
More of the on-going tasks
== Progress ==
* LLVM 7.1.0 Release for ARM & AArch64 [LLVM-546]
- Final candidate build in progress
* [GlobalISel] Map and select G_FCONSTANT [LLVM-552]
- Committed upstream
* [GlobalISel] Better support for small types [LLVM-553]
- In progress
== Plan ==
* LLVM-546, LLVM-553
[Conferences]
Linaro connect and EuroLLVM. Please see trip reports already posted. A
bit of a gruelling week of Travel going from Bangkok straight to
Brussels, with just a short half a day in between at home in
Cambridge.
[Activity]
- A number of reviews whilst away
- Started looking at how to build an embedded toolchain with Linaro's
ABE and work out how to fit it into their infrastructure.
Planned Absences
Holiday 12- 16th, back on Wednesday.
== Progress ==
* FDPIC
- Experimenting with stm32f469-disco
* GCC upstream validation:
- reported a few regressions
* GCC
- ubsan on bare-metal toolchain: enabling more multilibs triggered an
assert in the linker.
* Infra
- improved reporting of some jobs
== 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 update
== Progress ==
* LLVM 7.1.0 Release for ARM & AArch64 [LLVM-546]
- Uploaded RC1 for both ARM & AArch64
* [GlobalISel] Support debug info [LLVM-549]
- Added support for DBG_VALUE, seems to be enough for now
* [GlobalISel] Map and select G_FCONSTANT [LLVM-552]
- In progress
* IR SVE Reviews [LLVM-545]
- More reading, discussions etc
== Plan ==
* More of the same
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
More progress, but still crashing early. Crashes on first
memory access after swapping ttbr1. Debugging kernel on
guest and qemu on host simultaneously. So far, all the
numbers look right but still boom.
[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ]
Posted a v4 using the PT_NOTE, but still RFC-ish due to
missing abi for new mmap flag.
[VIRT-327 # Richard's upstream QEMU work ]
Posted v1+v2 of CPUNegativeOffsetState.
Posted v1 of a cleanup of target/riscv wrt decodetree.
[Other]
Upgraded the laptop from fedora 27 (out of support now),
to ubuntu 18.04 lts.
r~
[Activity]
[LLVM-542] Compiling zephyr with clang
- Prepared for presentation/discussion with colleagues at Connect next week.
- Made the installation process a bit more repeatable
- Added support for -Oz
[Intel-CET] patches to LLD (similar to BTI)
- Code-owner has redesigned the patches and they look a lot better and
more likely to go in. Shouldn't be too difficult to build BTI on top
of.
[LLVM-523] .ARM.exidx redesign
- Now committed, and has stuck for at least a day without needing to
be reverted.
Linaro Connect
- Preparations for hack room
- Gave dry run of presentation for Doughnuts. Will need to cut out
some material to get through in time.
Next week:
At Linaro Connect
Then at EuroLLVM
Then most likely on holiday for remainder of that week.
== Progress ==
* FDPIC
- Discovered that my stm32f429-disc1 board is not suitable for recent
Linux kernels (too large). Will experiment with stm32f469-disco
* GCC upstream validation:
- reported a few regressions
* misc (conf-calls, meetings, emails, ....)
- reviewed infra script patches
- fixed small issues after adding QEMU as a toolchain component in ABE
- added jobs to monitor Jenkins slaves
- fixed issues in benchmarking scripts
== 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 update
== Progress ==
* LLVM 7.1.0 Release for ARM & AArch64 [LLVM-546]
- Fixed our infra scripts to work for 7.1.0 (looks like it's the
first ever minor release since the new numbering scheme was
introduced)
- AArch64 is ready and green, ARM still in progress
* [Thumb GlobalISel] Bugfixes [LLVM-544]
- Committed the patch for alignment issues and 2 other patches for
1-bit value handling
- Selfhosted clang now passes check-all
* IR SVE Reviews [LLVM-545]
- More reading, installed armie etc
== Plan ==
* More of the same
Hi,
I am trying to cross-compile QEMU for aarch64 target using the below toolchain http://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/aarch6…
../configure --target-list=aarch64-softmmu --enable-kvm --enable-vhost-net --cross-prefix=~/Downloads/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
ERROR: pkg-config binary '/home/rokhanna/Downloads/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-pkg-config' not found
QEMU - https://github.com/qemu/qemu
Any pointers on where I can find pkg-config? Thanks in advance.
Thanks
Rohit
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Thanks Wookey and Richard.
I was able to resolve the pkg-config issue after installing it with -
apt install pkg-config-aarch64-linux-gnu
I modified my configure command to below -
./configure --target-list=aarch64-softmmu --enable-kvm --enable-vhost-net --cross-prefix=aarch64-linux-gnu-
Now I am running into dependency issue on glib-2.4 and gthread-2.0.
rokhanna@rokhanna-dev ~/dev/qemu.git $ ./configure --target-list=aarch64-softmmu --enable-kvm --enable-vhost-net --cross-prefix=aarch64-linux-gnu-
ERROR: glib-2.40 gthread-2.0 is required to compile QEMU
Thanks
Rohit
________________________________
From: Richard Henderson <richard.henderson(a)linaro.org>
Sent: Thursday, March 21, 2019 9:31 PM
To: Rohit Khanna; linaro-toolchain(a)lists.linaro.org
Cc: Santosh Shukla
Subject: Re: Cross compiling QEMU for aarch64
On 3/21/19 4:45 PM, Rohit Khanna wrote:
> Hi,
>
> I am trying to cross-compile QEMU for aarch64 target using the below toolchain http://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/aarch6…
>
>
> ../configure --target-list=aarch64-softmmu --enable-kvm --enable-vhost-net --cross-prefix=~/Downloads/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
>
> ERROR: pkg-config binary '/home/rokhanna/Downloads/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-pkg-config' not found
First, "--cross-prefix=aarch64-linux-gnu-".
It is a prefix, not a path. You should have
"$HOME/Downloads/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-gnu/bin" in your
path in order to use that compiler.
Second, pkg-config is not part of a toolchain, but part of an entire OS
distribution. If your host is debian or ubuntu, they ship a version configured
for aarch64 cross-compilation. Which is helpful because...
Third, you're going to need a *lot* of aarch64 libraries in order to build
QEMU. This is where OS support for cross-toolchains is key.
r~
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Progress: (short week, 3 days)
* VIRT-65 [QEMU upstream maintainership]
+ reviewed a few patchsets that had been lurking in my queue too long
+ trawled through the QEMU bug system for bugs we'd already fixed and
forgotten to close, bugs which need more info from the submitter,
and bugs which were very easy to fix
+ various other release related work
* Preparation for Connect next week
thanks
-- PMM
Linaro connect preparation:
- Finished Linaro Connect presentation on cross compilation with clang
-- Hoping to do a dry-run at Doughnuts this week assuming we can
resolve a potential clash with the IPG hands-on.
- Draft agenda for the hack-room produced.
[LLVM-523] ARM.exidx redesign
- Got approval, committed and then reverted my exceptions redesign due
some build-bot failures. Found another potential problem with
--emit-relocs that may be a bit more difficult to fix.
[BTI]
Continuing to review and make suggestions for Intel CET patch
(pre-requisite for BTI due to common use of .note.gnu.property
sections)
Some more communication with Linux Kernel port to Arm with respect to
assembler problems.
o LLVM
* Machine outliner:
- Debugging issue in LLVM bootstrap.
- Preparing BKK19 Hacking session presentation.
o Misc
* Various meetings and discussions.
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
Picked up my partial patch set and started on it again.
It is improved by having done the pauth/bti/mte work.
But still a work in progress.
[VIRT-327 # Richard's upstream QEMU work ]
Version 3 of tcg/ppc vector instructions.
Reviewed target/rx v4.
Fixed thread=single expansion of casp after Alex did all the
hard work tracking down the kernel failure, and writing me a
test case.
Looking into the size of the softmmu tlb expansion. Current
thinking is to move tlb out of CPUArchState into a new struct
that precedes env, so that the tlb is at small negative offsets
from env, so that {mask, table} is loadable with LDP/LDRD.
r~
Upstream Work ([VIRT-109])
==========================
- posted some CI clean-ups for next 4.0-rc
- posted {PATCH v1 0/3 for 4.0} reduce timeouts on Travis
Message-Id: <20190319124800.7454-1-alex.bennee(a)linaro.org>
- posted {PATCH} .travis.yml: reduce number of targets built while
disabling things Message-Id:
<20190321124857.28132-1-alex.bennee(a)linaro.org>
- will send PR on Monday
- while testing {Qemu-devel} {PATCH 3/4} memory: introduce
memory_global_after_dirty_log_sync Message-Id:
<20180209104546.29401-4-pbonzini(a)redhat.com>
- discovered regression -cpu max -accel tcg,thread=single with
ARM64_LSE_ATOMICS kernel breaks
- this is likely due to different code paths for non-MTTCG atomics
- however attempts [to reproduce in linux-user] have so far drawn
a blank
- have notified rth who can hopefully find the problem
[VIRT-109] https://projects.linaro.org/browse/VIRT-109
[to reproduce in linux-user]
https://github.com/stsquad/qemu/tree/for-4.0/mttcg-and-lse-atomics
Other
=====
- more work on Connect presentation
Absences
========
- Connect BKK19 (1-5th April 2019)
- holiday after Connect
Current Review Queue
====================
* {Qemu-devel} {multiprocess RFC PATCH 00/37} Initial support of multi-process qemu
Message-Id: <20190307072025.8041-1-elena.ufimtseva(a)oracle.com>
* {Qemu-devel} {PATCH 0/6} Refine exec
Message-Id: <20190321082555.21118-1-richardw.yang(a)linux.intel.com>
* {PATCH v5 00/26} KVM: arm64: SVE guest support
Message-Id: <1553017938-710-1-git-send-email-Dave.Martin(a)arm.com>
* {PATCH v4 00/19} Acceptance Tests: target architecture support
Message-Id: <20190312121150.8638-1-crosa(a)redhat.com>
* {PATCH 0/5} travis-ci: Build EDK2 roms
Message-Id: <20190311003052.13778-1-philmd(a)redhat.com>
* {RFC v2 00/38} Plugin support
Message-Id: <20181209193749.12277-1-cota(a)braap.org>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ tagged rc0 for QEMU 4.0.0; various other release-ish work
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ more progress with FP support: lazy state saving and the vlldm/vlstm
insns now implemented. FP support is now feature-complete, though
some bugs likely remain to be fixed.
* A day or so taken up by move to a new desktop machine (but
builds should go faster now!)
NB: I'm not working on Wednesday or Friday next week.
thanks
-- PMM
== Progress ==
* LLVM 8.0.0 Release for ARM & AArch64 [LLVM-526]
- LLVM 8.0.0 is out!
* [Thumb GlobalISel] Bugfixes [LLVM-544]
- Patch for alignment issues ready to commit next week
- With the patch, we can build clang successfully, but it fails some
of its tests
- Investigated one of the tests, it's failing because we end up
representing 'true' as '-1'. Going to prepare a patch for that next
week
* IR SVE Reviews [LLVM-545]
- Reviewed D32530 - Scalable Vector IR Type
* Buildbot babysitting
- Reported some failures upstream
- Complained about non-deterministic libfuzzer tests
== Plan ==
* LLVM-544, LLVM-545
== Progress ==
* FDPIC
- Setting up new stm32f429-disc1 board. Still not working with recent kernel
* GCC upstream validation:
- reported a few regressions
* GCC:
- (GNU-99) ubsan / bare-metal. No progress.
* misc (conf-calls, meetings, emails, ....)
- reviewing infra script patches
- added qemu as a toolchain component supported by ABE.
- merged tcwg_bmk branch into master
== 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 update
[LLVM-542] Compiling zephyr with clang
- Shared patches with Zephyr team lead, who has integrated them into a
private branch and has locally fixed some of the
incompatibilities/warnings
- Went through the Zephyr samples to get build instructions for the
ones compatible with Arm dev-boards.
[Intel-CET] patches to LLD (similar to BTI)
- Reviewed patches and made suggestion for an alternative design. Will
need to re-review the follow up this week.
[LLVM-523] .ARM.exidx redesign
- Responded to review comments, will need to ping again this week.
Linaro Connect
- Preparations for hack room
- Started on Presentation on cross compilation, need to finish slides this week.
[VIRT-343 # ARMv8.5-RNG, Random Number Generator ]
Three versions posted, with good review on the crypto side.
Generalized our existing infrastructure to use crypto quality
numbers by default, and decent deterministic numbers when
given the -seed command-line argument. Converted our existing
hw random number devices; implemented the AA64 registers;
filled in the PPC64 stubs; implemented the X86 tcg insns.
[VIRT-327 # Richard's upstream QEMU work ]
Reviewed and revised some target/hppa patches from Sven.
Final pull request for hppa for 4.0.
Final pull request for decodetree.
Revised the tcg extract2 patch set; delay this for 4.1.
r~
== This Week ==
* PR88839 (8/10)
- Addressing suggestions by Richard.
- Patch works for all cases except for VNx2DI/VNx2DF modes. I have a
workaround for those two cases but investigating for a better
approach.
* Validation (1/10)
- Submitted patches to merge tcwg_gnu branch into master for jenkins-scripts/
* Misc (1/10)
- Meetings
== Next Week ==
- Continue ongoing tasks
Upstream Work ([VIRT-109])
==========================
- posted {PATCH} scripts/qemugdb: re-license timers.py to GPLv2 or
later Message-Id: <20190311165538.6623-1-alex.bennee(a)linaro.org>
- started discussion on the state of QEMU CI Message-Id:
<6D897F0B-D7A6-4A16-93E0-3F68FF53B0BE(a)euphon.net>
- looked at GitLab's runners as an CI scaling option
- looks like [arm64 support has somewhat stalled]
- spammed Peter with PRs for Tuesday's softfreeze
- posted {PULL 00/26} final testing updates for 4.0 Message-Id:
<20190312170931.25013-1-alex.bennee(a)linaro.org>
- including {PATCH v2 0/7} testing/next for softfreeze Message-Id:
<20190312105547.4755-1-alex.bennee(a)linaro.org>
- and {PATCH v4 00/21} final tcg tests for 4.0 Message-Id:
<20190312155947.14918-1-alex.bennee(a)linaro.org>
- posted {PULL 0/5} gitdm updates for 4.0 Message-Id:
<20190312193458.9171-1-alex.bennee(a)linaro.org>
[VIRT-109] https://projects.linaro.org/browse/VIRT-109
[arm64 support has somewhat stalled]
https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725
Other
=====
- more work on Connect presentation
Completed Reviews [1/1]
=======================
{Qemu-devel} {PATCH} ci: store Patchew configuration in the tree
Message-Id: <20190315091941.23669-1-pbonzini(a)redhat.com>
Absences
========
- Connect BKK19 (1-5th April 2019)
- holiday after Connect
Current Review Queue
====================
* {PATCH v4 00/19} Acceptance Tests: target architecture support
Message-Id: <20190312121150.8638-1-crosa(a)redhat.com>
* {PATCH 0/5} travis-ci: Build EDK2 roms
Message-Id: <20190311003052.13778-1-philmd(a)redhat.com>
* {RFC v2 00/38} Plugin support
Message-Id: <20181209193749.12277-1-cota(a)braap.org>
* {PATCH+RFC 0/6} target/arm: Define cortex-a{73,75,76}
Message-Id: <20190223023957.18865-1-richard.henderson(a)linaro.org>
* {Qemu-devel} {PATCH 0/9} tcg: Add tcg_gen_extract2_{i32,i64}
Message-Id: <20190307144126.31847-1-richard.henderson(a)linaro.org>
* {Qemu-devel} {RFC PATCH 0/6} pc: Support firmware configuration with -blockdev
Message-Id: <20190225183757.27378-1-armbru(a)redhat.com>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ lots of code review and other work for softfreeze
+ tracked down the bug that caused regressions running UEFI in a
KVM guest with commit 823e1b3818f9b1, and sent out a fix
thanks
-- PMM
== Progress ==
* FDPIC
- Setting up new stm32f429-disc1 board. Boots OK with buildroot's
default 4.11 kernel. Boot seems to fail starting with 4.13 (recent
kernel needed to have FDPIC support)
* GCC upstream validation:
- reported a few regressions
* GCC:
- (GNU-99) ubsan / bare-metal. No progress.
* misc (conf-calls, meetings, emails, ....)
- reviewing infra script patches
- adding qemu as a toolchain component supported by ABE. A bit
convoluted because of manifest handling.
== 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
- add QEMU to list of components built by ABE
== Progress ==
* Out of office 1 day (Thursday)
* [Thumb GlobalISel] Bugfixes [LLVM-544]
- The test-suite compiles and executes without failures (with
fallback to DAG ISel)
- We get some bus errors in the selfhost, which are due to unaligned
64-bit stores. Apparently when alignment checks were introduced in the
legalizer, they were only used for types < 32 bits. Currently testing
a patch to fix this oversight.
* LLVM 8.0.0 Release for ARM & AArch64 [LLVM-526]
- rc5 looks good on AArch64, ARM is still in progress (waited for LSS-570)
== Plan ==
* Wrap up LLVM-544
* Upload rc5 when ARM is ready
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Posted v4, with system mode only.
[VIRT-298 # ARMv8.4-CondM, Condition flag manipulation ]
[VIRT-329 # ARMv8.5-CondM, Condition flag manipulation ]
[VIRT-337 # ARMv8.0-SB, Speculation Barrier ]
[VIRT-338 # ARMv8.0-PredInv, Prediction Invalidation ]
[VIRT-330 # ARMv8.5-FRINT, Floating-point to integer ]
All upstream.
[VIRT-327 # Richard's upstream QEMU work ]
Reviewed s390x vector patch set 3.
Reviewed renesas rx patch set 3.
Posted some patches and thoughts for
https://bugs.linaro.org/show_bug.cgi?id=4274
Implemented extract2 as a tcg opcode.
Minor hppa bug fixes.
Lots more work on decodetree and A32+T32+T16 conversion.
r~
- Intel CET review (Related to BTI support in LLD), raised issue of
multiple PT_NOTE sections one per alignment
https://reviews.llvm.org/D59120 , commented on command line options.
- LLVM-523 redesigned the LLD handling of ARM exidx sections to
centralise more of the Arm specific implementation details in one
place. Hope to post upstream to get some movement on the review to add
missing .ARM.exidx sections for chrome OS team.
- LLVM-542 Managed to build most of the Zephyr examples for clang,
shared patches to do so with zephyr tech lead.
- Some research for some ABI topics.
- Some thoughts for Linaro connect activities, started team calendar.
Next week:
- Start on my connect presentation
o LLVM
* Machine outliner:
- Stack alignment and refactoring.
- Start to prepare BKK19 talk
* Bots babysitting
* Built 8.0.0-rc4 binaries for x86 and ARM, got issues to start the job on D05
o Misc
* Completed BKK19 and EuroLLVM trips.
* Various meetings and discussions.
== Progress ==
* FDPIC
- (GNU-411) GDB: debugging problems with FDPIC support. Working on
setup of an stm32 board.
* 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 ==
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
- add QEMU to list of components built by ABE
Reply
Forward
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ code review
- add watchdog device to stellaris boards
- bcm2836 "local timer" device
- RTH's rolled-up patchset for SB, PredInv, CondM, FRINT extensions
- Eric's patchset to allow the 'virt' board to have more than 255GB of RAM
- a patchset to add a "generic nommu" board for NiosII
+ assembled a target-arm pull request for softfreeze
+ fixed some minor issues with the "build sphinx docs" patches,
and got them into master (and then fixed some more minor issues...)
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ progress on M-profile floating point:
- finished first draft of changes to exception handling code
- this is now on hold as we are into softfreeze for QEMU 4.0 and other
work for that release will take priority for the next few weeks
thanks
-- PMM
== This Week ==
* PR88839 - Poor implementation of blend like permutes (4/10)
- Addressing suggestions by Richard on patch
* GCC vectorizer (2/10)
- Background reading
* Validation (1/10)
- Added more bootstrap configs for tcwg_gnu job
- Committed patch to abe to enable bootstrap implicitly when buildconfig is set.
- Started tracking for tcwg_gnu ci job (init_configuration == false).
* Public holiday (2/10)
* Misc (1/10)
- Meetings
== Next Week ==
- Continue ongoing tasks
o LLVM
* Back to machine outliner after vacation
- Rebased on upstream master branch
- Working on stack alignment and refactoring.
o Misc
* Preparing BKK19 and EuroLLVM trips.
* Various meetings and discussions.
* PR88838
- I have a patch which solves this.
* adds iv in Pmode but compare_type in 32bit
- It exposes a latent bug in fwprop in regression testing
- Looking into it
== Plan ==
* Complete above PRs
* Look at GDB BZ #21221 - gdb hangs while stepping an empty loop
Progress:
[VIRT-274 # ARMv8.2-FHM, Floating-point multiplication variant ]
Now upstream.
[VIRT-298 # ARMv8.4-CondM, Condition flag manipulation ]
[VIRT-329 # ARMv8.5-CondM, Condition flag manipulation ]
[VIRT-337 # ARMv8.0-SB, Speculation Barrier ]
[VIRT-338 # ARMv8.0-PredInv, Prediction Invalidation ]
[VIRT-330 # ARMv8.5-FRINT, Floating-point to integer ]
Posted an omnibus of SB+PredInv+CondM+FRINT that I have
labeled "v3", as 3 > any individual revision previously used.
[VIRT-327 # Richard's upstream QEMU work ]
Reviewed s390x vector patch set v2.
Implemented pattern groups in decodetree.
Prototyped A32 conversion to decodetree;
started a second revision that incorporates T32.
Started looking at
https://bugs.linaro.org/show_bug.cgi?id=4274
I can swizzle things around by changing the group name from
"cp_regs" to the predefined "system", but somehow those regs
are *also* registered with "general". Which means the
undesired behaviour by which "info regs" prints all of the
system registers still exists.
r~