linaro-toolchain June 2019

linaro-toolchain@lists.linaro.org

11 participants
30 discussions

[ACTIVITY] week ending Jun. 23 2019

by Alex Bennée

QEMU Tooling ([VIRT-252]) ========================= QEMU plugin support ([VIRT-280]) - going through review comments and re-working physaddr support [VIRT-280] https://projects.linaro.org/browse/VIRT-280 GSoC Mentoring ([VIRT-348]) - first proof-of-concept posted {Qemu-devel}{PATCH 0/3} Collecting TB Execution Frequency Message-Id: <20190614132252.11621-1-vandersonmr2(a)gmail.com> - did an initial review of series [VIRT-348] https://projects.linaro.org/browse/VIRT-384 Upstream Work ([VIRT-109]) ========================== - posted {PATCH v1 00/17} testing/next (Travis fixes, more tests/vm) Message-Id: <20190619194021.8240-1-alex.bennee(a)linaro.org> [VIRT-109] https://projects.linaro.org/browse/VIRT-109 Completed Reviews [4/4] ======================= {Qemu-devel} {PATCH 0/3} Collecting TB Execution Frequency Message-Id: <20190614135332.12777-1-vandersonmr2(a)gmail.com> {Qemu-arm} {PATCH v2 00/23} Support disabling TCG on ARM Message-Id: <20190615154352.26824-1-philmd(a)redhat.com> {RFC PATCH 0/2} target: Build with CONFIG_SEMIHOSTING disabled Message-Id: <20190531154735.20809-1-philmd(a)redhat.com> {PATCH v4 00/11} tests/vm: serial console autoinstall, misc fixes. Message-Id: <20190617043858.8290-1-kraxel(a)redhat.com> Absences ======== - June 21st Current Review Queue ==================== * {PATCH} Makefile: Rename the 'vm-test' target as 'vm-help' Message-Id: <20190531064341.29730-1-philmd(a)redhat.com> * {PATCH v2 0/9} configure: Fix softmmu --static linking Message-Id: <20190614100718.14019-1-philmd(a)redhat.com> * {PATCH 0/8} Miscellaneous acceptance test and Travis CI improvements Message-Id: <20190607152223.9467-1-crosa(a)redhat.com> * {Qemu-devel} {PATCH v22 0/7} QEMU AVR 8 bit cores Message-Id: <20190614131724.33928-1-mrolnik(a)gmail.com> * {RFC PATCH v2 0/8} arm64/sve: First steps towards optimizing syscalls Message-Id: <20190613161656.20765-2-julien.grall(a)arm.com> * {Qemu-devel} {PATCH v2 00/11} monitor: Split monitor.c in core/HMP/QMP/misc Message-Id: <20190611134043.9524-1-kwolf(a)redhat.com> -- Alex Bennée

5 years, 5 months

[ACTIVITY] week ending 16 June, plus 2 days

by Richard Henderson

Week ending 23 June is very short. * Patch review - target/ppc vsr cleanup - target/tricore translator loop conversion - target/arm vfp decodetree cleanup - cortex-strings strrchr fix - continuing on the plugin api * Xilinx meeting * Fix qemu assert for clyon - Found two other bugs in the process. * Debugging my own USHR/SSHR patch vs aa32. r~

5 years, 5 months

[ACTIVITY] report week ending 18 June

by Peter Maydell

Progress: (very short week, 2 days) * VIRT-65 [QEMU upstream maintainership] + found and sent patches for a handful of minor M-profile bugs * VIRT-268 [QEMU support for dual-core Cortex-M Musca board] + the final patches for this have now gone upstream and I have marked the JIRA issue as resolved. There may still be minor bug fixes but we can handle those under the usual 'upstream maintainership' JIRA thanks -- PMM

5 years, 5 months

compilers under the hood

by Siddhesh Poyarekar

Hello folks, I got a few people asking me to do this in the last Connect, so I've proposed a beginner session that explores gcc under the hood. The tentative plan I have for the talk is: 1. A high level view of how the source code is laid out 2. Front end, middle end, backend. This includes a high level introduction of GIMPLE and machine descriptions 3. A walkthrough of one or two simple programs and usage of diagnostic flags like -fdump-* Additional suggestions are most welcome. Also, I was thinking maybe it would be good to have a llvm under the hood talk along similar lines. Thoughts? Siddhesh

5 years, 5 months

[ACTIVITY] week ending 14th June 2019

by Peter Smith

[LLVM-571] Build GNU rmprofile toolchain with Linaro scripts (abe) The existing build-system was only set up to build the A-profile bare metal toolchain. Managed to find right combination of flags and modifications to get a toolchain that zephyr can use. [LLVM-158] Buildbot maintenance An interesting failure introduced in LLD, but causing segfaults in 2-stage build, now fixed. [LLVM-542] Zephyr code size investigation - Rebased modifications to Zephyr - Wrote script to build all the examples with GCC and Clang - Fixed problems with modifications found by building all the examples - Clang built helloworld no longer booting, need to investigate - Found some areas for more investigation: -- llvm-objcopy missing --gap-fill (used by one of the sample programs) -- lld missing --print-memory-usage, while I'm using gcc for the main link, zephyr build system seems to be feature testing using clang bare metal default linker (lld) -- clang always generates .note.GNU.stack, gcc embedded does not, leading to lots of orphan section warnings. Probably best solved by linker script modification.

5 years, 5 months

[ACTIVITY] report week ending 14 June

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + some work on getting Sphinx to generate manpages, with a conversion of the qemu-ga manpage from texinfo as the demonstration case + set up to run pre-merge tests on our packet.net qemu-test machine rather than the gcc compile farm one (as the latter is running an ancient ubuntu whose python is now too old to build QEMU with) + sent some follow-on cleanup patches now that VFP decodetree is in master * VIRT-268 [QEMU support for dual-core Cortex-M Musca board] + sent out patches which correctly make the Cortex-M33 (and the -M4) implement single-precision-only floating point, so the double-precision instructions UNDEF as they should + once those and the other on-list patches have made their way through code review and into master this epic will be complete thanks -- PMM

5 years, 5 months

[ACTIVITY] week ending Jun. 16 2019

by Alex Bennée

QEMU Tooling ([VIRT-252]) ========================= QEMU plugin support ([VIRT-280]) - posted {PATCH v3 00/50} tcg plugin support Message-Id: <20190614171200.21078-1-alex.bennee(a)linaro.org> GSoC Mentoring ([VIRT-348]) - first proof-of-concept posted {Qemu-devel}{PATCH 0/3} Collecting TB Execution Frequency Message-Id: <20190614132252.11621-1-vandersonmr2(a)gmail.com> Upstream Work ([VIRT-109]) ========================== - 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> - spent some time debugging serial emulation and broken Ubuntu QEMUs - finally merged {PULL v3 00/40} testing, gdbstub and cputlb fixes Message-Id: <20190612173121.21057-1-alex.bennee(a)linaro.org> Other Tasks =========== - A bit more discussion on RPMB and QEMU secure options Completed Reviews [4/4] ======================= {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-arm} {PATCH 0/4} Disable FPU/DSP for CPU0 on musca-a and mps2-an521 Message-Id: <20190517174046.11146-1-peter.maydell(a)linaro.org> {PATCH 0/4} tests/vm: misc fixes and optimizations Message-Id: <20190613130718.3763-1-crosa(a)redhat.com> {Qemu-arm} {PATCH v2} net: cadence_gem: fix compilation error when debug is on Message-Id: <20190611145556.12940-1-rfried.dev(a)gmail.com> Current Review Queue ==================== * {Qemu-devel}{PATCH 0/3} Collecting TB Execution Frequency Message-Id: <20190614132252.11621-1-vandersonmr2(a)gmail.com> * {PATCH v2 0/9} configure: Fix softmmu --static linking Message-Id: <20190614100718.14019-1-philmd(a)redhat.com> * {PATCH 0/8} Miscellaneous acceptance test and Travis CI improvements Message-Id: <20190607152223.9467-1-crosa(a)redhat.com> * {Qemu-devel} {PATCH v22 0/7} QEMU AVR 8 bit cores Message-Id: <20190614131724.33928-1-mrolnik(a)gmail.com> * {RFC PATCH v2 0/8} arm64/sve: First steps towards optimizing syscalls Message-Id: <20190613161656.20765-2-julien.grall(a)arm.com> * {Qemu-devel} {PATCH v2 00/11} monitor: Split monitor.c in core/HMP/QMP/misc Message-Id: <20190611134043.9524-1-kwolf(a)redhat.com> -- Alex Bennée

5 years, 5 months

[ACTIVITY] 10-14 June 2019

by Christophe Lyon

== Progress == * FDPIC - GCC: No progress, still waiting for feedback * GCC upstream validation: - reported a few regressions. * GCC: - noinit attribute: patch posted for upstream review * misc: - training 3 days == Next == GCC: - handle feedback on FDPIC and noinitpatches - UBSAN/bare-metal: do more testing

5 years, 5 months

[ACTIVITY] 10 - 14 June 2019

by Diana Picus

== Progress == * Catching up after holidays * [GlobalISel] Refactor CallLowering [LLVM-568] - Still in progress, but I fixed the AMDGPU failure - Decided to go a bit deeper than initially intended, since it gets really awkward otherwise * IR SVE Reviews [ LLVM-545] - New version of the patch was posted, had a quick look == Plan == * Continue LLVM-568 * Start LLVM-134 (LLVM SPEC2k6 Performance Analysis Leftovers from BUD17) * LLVM-545 (IR SVE Reviews) - Have a look at the new, revised patch

5 years, 5 months

Request for comment: adding support for coresight etm as branch trace mechanism in gdb

by zied guermazi

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

5 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain June 2019