linaro-toolchain November 2020

linaro-toolchain@lists.linaro.org

12 participants
20 discussions

[ACTIVITY] 9-13 November 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions/new failures * GCC - Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: no feedback - MVE autovectorization: started patterns updates (vand, vorr, veor) * Misc - investigated LP bug 1747966 (https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966) there is a fix in binutils upstream: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0e6a3f07f50723d18… * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. * infra: - debugging issues with our docker containers == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

4 years

[ACTIVITY] report week ending 13 Nov

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] + investigated and fixed a bug that had been lurking unfixed in our n800 models for years which prevented guest boot of Maemo images + docs tidyup: moved "orphan" rST documents into the manual structure so they actually get shipped to users + usual release candidate related work * VIRT-364 [QEMU support for ARMv8.1-M extensions] + working on handling for new FP system registers; the FPCXT regs in particular have some tricky corners... thanks -- PMM

4 years

[ACTIVITY] week ending 8 Nov 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] * Fix neon register offsets big-endian hosts. * Fix neon register offsets for VTBL. * Working through a 4th revision of float128_muladd. * Random patch review and bug fixes. [UM-61 # TCG Core Maintainership ] * Two revisions of split w^x patch set. r~

4 years

Demo of using etm traces on arm for instructions and functions recording and reverse debugging

by Zied Guermazi

hi all, to demonstrate extending gdb to use etm traces for implementing btrace on arm processors, I have made this video available on youtube https://youtu.be/ptKbJRNUqUI users can then have access to process record and replay, on instructions and functions level (https://sourceware.org/gdb/current/onlinedocs/gdb/Process-Record-and-Replay…) and reverse debugging(https://www.gnu.org/software/gdb/news/reversible.html) we have all functionalities available for intel PT except tracing multi-threaded applications. In this demo I have "reconstructed" the cspr register to enable setting breakpoints in reverse debugging. it is still dirty (adds arm specific register to an architecture agnostic structure) but it shows that it works when implemented properly Kind Regards Zied Guermazi

4 years

[ACTIVITY] 2-6 November 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions/new failures * GCC - PR96767: patch committed - PR96770: patch committed - patch for C++ thunks with -mpure-code and cortex-m0: patches committed - Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: handling feedback * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. * infra: - debugging issues with our docker containers == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

4 years

[ACTIVITY] week ending Nov. 8 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - Raised two more Xen related cards, [STR-19] and [STR-20] [STR-19] <https://projects.linaro.org/browse/STR-19> [STR-20] <https://projects.linaro.org/browse/STR-20> VirtIO Portability Demo ([STR-13]) ================================== - syned on current status of demo and discussed options - attempted to record the KVM demo, killed my MachiatoBin with load - another go on Monday [STR-13] <https://projects.linaro.org/browse/STR-13> QEMU Support for Xen ([STR-20]) =============================== - posted [RFC PATCH 00/15] Xen guest-loader and arm64 build fixes/enhancements Message-Id: <20201105175153.30489-1-alex.bennee(a)linaro.org> [STR-20] <https://projects.linaro.org/browse/STR-20> Upstream Work ([QEMU-109]) ========================== - finally got round to looking at rth's [128 bit softfloat proposal] - posted [PATCH v2] docs: add some notes on the sbsa-ref machine Message-Id: <20201104165254.24822-1-alex.bennee(a)linaro.org> [128 bit softfloat proposal] <https://github.com/stsquad/qemu/tree/review/rth-sf128> Other ===== - TSC Review prep - Annual Review Completed Reviews [0/0] ======================= Absences ======== - Home schooling Current Review Queue ==================== * [PATCH 0/8] arm/virt: add usb support Message-Id: <20201023071022.24916-1-kraxel(a)redhat.com> Added: <2020-10-27 Tue> * [PATCH 0/4] riscv: Add semihosting support [v10] Message-Id: <20201026212853.92880-1-keithp(a)keithp.com> Added: <2020-10-27 Tue> * [PATCH v2 0/7] xen/arm: Unbreak ACPI Message-Id: <20201023154156.6593-1-julien(a)xen.org> Added: <2020-10-24 Sat> * [PATCH v3 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI) Message-Id: <20201014052140.1146924-1-crosa(a)redhat.com> Added: <2020-10-14 Wed> -- Alex Bennée

4 years

[ACTIVITY] report week ending 6 Nov

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + usual release cycle work + Our Coverity-Scan issues had been left untended a bit too long: went through them doing triage, reporting them back to patch submitters, and writing a few fixes for some of the easy ones + That took me down a rabbit-hole of fixing some issues with our sparc64 usermode emulation so I could demonstrate that the coverity fixes hadn't broken anything... thanks -- PMM

4 years

GDB: status of branch tracing on arm processors using coresight etm traces

by Zied Guermazi

hi all I am announcing updates in the implementation of branch tracing using coresight etm in GDB. in this update, functions and instruction history are running successfully on single threaded applications. reverse debugging is basically working with the limitation that sometimes cspr register (register 25) is required but current implementation does not provide it. the feature requires linux kernel v 4.19 or higher with manual etm sink setup. 5.9.1 or higher for automatic sink selection. GDB gdb.btrace test suite was adapted to run on arm processors. here is the summary of the gdb.btrace test results executed on an STM32MP157 (ARM cortex A7) with Linux kernel 5.9.1 === gdb Summary === # of expected passes 390 # of unexpected failures 119 # of unsupported tests 4 following tests are 100% successful: - buffer-size - enable - instruction_history - function_call_history - data - delta - cpu - gcore - record_goto-step - dlopen - vdso - segv GDB source code is available on https://github.com/gzied/binutils-gdb/tree/gdb_arm_coresight many thanks to GDB and linaro communities for their support Kind Regards Zied Guermazi

4 years

Re: GDB: etm traces decoding and breakpoints for arm targets

by Zied Guermazi

hi Thanks Mike for your support, it was very helpful. to put everything together, on arm, gdb inserts a sw breakpoint by patching the code with an undefined instruction ( see comments in arm-tdep.c line7687) when a breakpoint is hit, an exception number 9 "Undefined Instruction exception" is raised and a branch packet with this info is generated in etm traces, the trap is get handled by the kernel and it sends the appropriate signal to gdb process. when the user continues the execution, gdb patches back the code and executes the instruction. this leads to the instruction traced twice with an exception in between, the same happens for next executed instruction here is the log of decoded packets [btrace] [ftrace] update insn: fun = main, file = ./function_call_history.c, level = 0, insn = [1; 2) cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE */<= first execution attempt that raises an undefined instruction exception/* trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400534 end addr = 0x400536 instructions count = 1 last_i_type: OCSD_INSTR_OTHER last_i_subtype: OCSD_S_INSTR_NONE last instruction was executed last instruction size: 2 [btrace] [ftrace] update insn: fun = main, file = ./function_call_history.c, level = 0, insn = [1; 3) cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_EXCEPTION */<= the exception is traced/* trace_chan_id: 18 exception number: 9 */<= undefined instruction exception/* cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_TRACE_ON cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_PE_CONTEXT cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE */<= execution of the original instruction/* trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400534 end addr = 0x400536 instructions count = 1 last_i_type: OCSD_INSTR_OTHER last_i_subtype: OCSD_S_INSTR_NONE last instruction was executed last instruction size: 2 as the code was changed during execution, it can not be reconstructed during traces decoding. in addition, and for tracing applications running on Linux, we are not interested in capturing raised exceptions, we can consider rolling back last instruction in ftraces. As this is not obvious, we can consider ignoring the repeated instruction as a workaround. for tracing bare metal software, we need to keep tracing exception, so we can have a flag for ignoring exceptions, and activate or dis-activate it according to the context. what do you think about it, shall I go for implementing it as described above? Kind Regards Zied Guermazi On 02.11.20 12:59, Mike Leach wrote: > Hi Zeid, > > On Sat, 31 Oct 2020 at 23:11, Zied Guermazi <zied.guermazi(a)trande.de> wrote: >> hi, >> >> while testing the implementation in gdb of branch tracing on arm >> processors using etm, I faced the the situation where a breakpoint was >> set, was hit and then the execution of the program was continued. While >> decoding generated traces, I got the address of the breakpoint >> (0x400552) executed twice, and then the following address (0x400554) >> also executed twice. the instruction at (0x400554) is a BL ( a function >> call) and the second execution corrupts the function history. >> >> here is a dump of generated trace elements >> >> >> --------------------------------- >> trace_chan_id: 18 >> isa: CS_ETM_ISA_T32 >> start addr = 0x400552 >> end addr = 0x400554 >> instructions count = 1 >> last_i_type: OCSD_INSTR_OTHER >> last_i_subtype: OCSD_S_INSTR_NONE >> last instruction was executed >> last instruction size: 2 >> --------------------------------- >> trace_chan_id: 18 >> isa: CS_ETM_ISA_T32 >> start addr = 0x400552 >> end addr = 0x400554 >> instructions count = 1 >> last_i_type: OCSD_INSTR_OTHER >> last_i_subtype: OCSD_S_INSTR_NONE >> last instruction was executed >> last instruction size: 2 >> --------------------------------- >> trace_chan_id: 18 >> isa: CS_ETM_ISA_T32 >> start addr = 0x400554 >> end addr = 0x400558 >> instructions count = 1 >> last_i_type: OCSD_INSTR_BR >> last_i_subtype: OCSD_S_INSTR_BR_LINK >> last instruction was executed >> last instruction size: 4 >> --------------------------------- >> trace_chan_id: 18 >> isa: CS_ETM_ISA_T32 >> start addr = 0x400554 >> end addr = 0x400558 >> instructions count = 1 >> last_i_type: OCSD_INSTR_BR >> last_i_subtype: OCSD_S_INSTR_BR_LINK >> last instruction was executed >> last instruction size: 4 >> >> the explanation I have for this behavior is that : >> >> -when setting the software breakpoint, the memory content of the >> instruction (at 0x400552) was altered to the instruction BKPT, >> >> -when the breakpoint was hit, the original opcode was set at (0x400552) >> and a BKPT was set to the next instruction address (0x400554), then the >> execution was continued >> >> -when the second breakpoint (0x400554) was hit, the a BKPT opcode was >> set at (0x400552) and the original opcode was set at (0x400554) then the >> execution was continued >> >> I am using the function "int target_read_code (CORE_ADDR memaddr, >> gdb_byte *myaddr, ssize_t len)" to give program memory content to the >> decoder. so the collected etm traces are correct, but, as memory was >> altered in between, the decoder is "cheated". >> >> I need to identify the re-execution of code due to breakpoint handling, >> and roll back its impact on etm decoding. >> >> is there a mean to get the actual content of program memory including >> patched addresses? >> >> is there a means of getting the history of patched addresses during the >> debugging of a program? >> >> what is the type and subtype of a BKPT instruction in a decoded trace >> elements? >> > I can only really comment on this question. The type / subtype > information in the output from the decoder is generated from the > decoder walking the memory image of the executed trace - not from the > trace packets themselves. > The decoder classifies instructions according to how they will affect > trace flow with the "other" category being set for the majority of > instructions. The categories are: other, branch, indirect branch, ISB > / DSB / DMB / WFI / WFE. > These are important in program flow trace (PTM 1.x, ETM 4.x) as these > determine which instruction we attach the E/N atoms to. BKPT will be > classified as "other", if it is seen, as it has no effect on normal > program flow. It will cause an exception which has a specific trace > packet format. > > Regards > > Mike > > >> do you have any other idea for handling this situation? >> >> >> I am attaching the source code of the program as well as the >> disassembled binary. the code was compiled as an application running on >> linux on an ARMv7 A (STM32MP157 SoC). the breakpoint was set at line 43 >> in the source code (line 238 in the disassembled code) >> >> >> Kind Regards >> >> Zied Guermazi >> >> _______________________________________________ >> CoreSight mailing list >> CoreSight(a)lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/coresight > >

4 years

GDB: etm traces decoding and breakpoints for arm targets

by Zied Guermazi

hi, while testing the implementation in gdb of branch tracing on arm processors using etm, I faced the the situation where a breakpoint was set, was hit and then the execution of the program was continued. While decoding generated traces, I got the address of the breakpoint (0x400552) executed twice, and then the following address (0x400554) also executed twice. the instruction at (0x400554) is a BL ( a function call) and the second execution corrupts the function history. here is a dump of generated trace elements --------------------------------- trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400552 end addr = 0x400554 instructions count = 1 last_i_type: OCSD_INSTR_OTHER last_i_subtype: OCSD_S_INSTR_NONE last instruction was executed last instruction size: 2 --------------------------------- trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400552 end addr = 0x400554 instructions count = 1 last_i_type: OCSD_INSTR_OTHER last_i_subtype: OCSD_S_INSTR_NONE last instruction was executed last instruction size: 2 --------------------------------- trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400554 end addr = 0x400558 instructions count = 1 last_i_type: OCSD_INSTR_BR last_i_subtype: OCSD_S_INSTR_BR_LINK last instruction was executed last instruction size: 4 --------------------------------- trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400554 end addr = 0x400558 instructions count = 1 last_i_type: OCSD_INSTR_BR last_i_subtype: OCSD_S_INSTR_BR_LINK last instruction was executed last instruction size: 4 the explanation I have for this behavior is that : -when setting the software breakpoint, the memory content of the instruction (at 0x400552) was altered to the instruction BKPT, -when the breakpoint was hit, the original opcode was set at (0x400552) and a BKPT was set to the next instruction address (0x400554), then the execution was continued -when the second breakpoint (0x400554) was hit, the a BKPT opcode was set at (0x400552) and the original opcode was set at (0x400554) then the execution was continued I am using the function "int target_read_code (CORE_ADDR memaddr, gdb_byte *myaddr, ssize_t len)" to give program memory content to the decoder. so the collected etm traces are correct, but, as memory was altered in between, the decoder is "cheated". I need to identify the re-execution of code due to breakpoint handling, and roll back its impact on etm decoding. is there a mean to get the actual content of program memory including patched addresses? is there a means of getting the history of patched addresses during the debugging of a program? what is the type and subtype of a BKPT instruction in a decoded trace elements? do you have any other idea for handling this situation? I am attaching the source code of the program as well as the disassembled binary. the code was compiled as an application running on linux on an ARMv7 A (STM32MP157 SoC). the breakpoint was set at line 43 in the source code (line 238 in the disassembled code) Kind Regards Zied Guermazi

4 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain November 2020