linaro-toolchain

linaro-toolchain@lists.linaro.org

12 participants
5687 discussions

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

5 years, 4 months

[ACTIVITY] report week ending 30 Oct

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + more code review and assembly of the last pull request for softfreeze for QEMU 5.2 + noticed that our AArch32 Neon emulation doesn't work on big-endian hosts. RTH fixed most of this and I wrote a couple of patches to fix bugs in some insns that were only noticeable once we got out of the "anything working on vectors is broken" state :-) + looked at trying to get our documentation to build with Sphinx 3, which has made some annoying incompatible changes to the markup it accepts * VIRT-364 [QEMU support for ARMv8.1-M extensions] + started implementation of new insns VSCCLRM, CLRM, and the new FP sysregs accessed via VLDR/VSTR KVM Forum (virtual conference) was this week. Some interesting talks: * Will Deacon on what Google is doing to introduce KVM into Android * Marc Zyngier/Christoffer Dall on a virtual-only interrupt controller that's less of a big lump of code to put on a security boundary than a full-on GIC * Salil Mehta on the current problems with doing Arm vCPU hotplug in KVM thanks -- PMM

5 years, 4 months

[ACTIVITY] week ending Nov. 1 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - Stratos sync call, discussion on AGL demo - Google sync call - Created a first cut of additional Xen work cards under [STR-16] [STR-16] <https://projects.linaro.org/browse/STR-16> VirtIO Portability Demo ([STR-13]) ================================== - Created a [branch with the experimental ioreq (virtio-mmio) support] - developing understanding of the ioreq piece - posted [PATCH] meson.build: fix building of Xen support for aarch64 Message-Id: <20201028174406.23424-1-alex.bennee(a)linaro.org> - continued work and expanded into [branch to clean-up and add "virt" machine] [STR-13] <https://projects.linaro.org/browse/STR-13> [branch with the experimental ioreq (virtio-mmio) support] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/expe…> [branch to clean-up and add "virt" machine] <https://github.com/stsquad/qemu/tree/xen/add-xen-virt-machine> Upstream Work ([QEMU-109]) ========================== - posted [PULL 0/8] testing and misc (gitdm, gitlab, docker, make) Message-Id: <20201027095938.28673-1-alex.bennee(a)linaro.org> [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> Other ===== - KVM Forum 2020 Completed Reviews [2/2] ======================= [PATCH 0/2] tcg: optimize across branches Message-Id: <20201013222330.173525-1-richard.henderson(a)linaro.org> [PATCH 00/15] remove bios_name variable Message-Id: <20201026143028.3034018-8-pbonzini(a)redhat.com> Absences ======== - Welsh lockdown next week - Children at home 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

5 years, 4 months

Please make clang-cmake-armv7-selfhost-neon and clang-cmake-thumbv7-full-sh green

by Galina Kistanova

5 years, 4 months

[ACTIVITY] 26-30 October 2020

by Christophe Lyon

* 2 days off == Progress == * GCC upstream validation: - reported several regressions/new failures * GCC - PR96767: patch accepted - PR96770: patch accepted - patch for C++ thunks with -mpure-code and cortex-m0: iterating, almost OK - Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: no feedback * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. * infra: - debugging issues with our docker containers - added monitoring for disk space on dev machines == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

5 years, 4 months

[ACTIVITY] week ending 25 Oct 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] More time than I expected on float128_muladd, adjusting the codebase to share code with float64_muladd. [VIRT-339 # ARMv8.5-BTI, Branch Target Identification ] Posted v12, adjusting one of the smoke tests vs a distro linker bug (fixed in mainline). r~

5 years, 5 months

[ACTIVITY] week ending Oct. 25 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== VirtIO RPMB ([STR-5]) ===================== - Synced with with Ulf/Illias on enhancements for eMMC stacks - need to support 512 frames somehow for the CSD, everything else should be fine [STR-5] <https://projects.linaro.org/browse/STR-5> VirtIO Portability Demo ([STR-13]) ================================== - More work on trying to get Xen working on MB - more failures, this time GIC related. Might just stick to KVM - Created a [branch with the experimental ioreq (virtio-mmio) support] - Got Virgl based acceleration working on both TCG and KVM - so now fast graphics! - posted [PATCH v1 0/4] add guest-loader (for direct Xen boot) Message-Id: <20201021170842.25762-1-alex.bennee(a)linaro.org> [STR-13] <https://projects.linaro.org/browse/STR-13> [branch with the experimental ioreq (virtio-mmio) support] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/expe…> Upstream Work ([QEMU-109]) ========================== - Some discussion on converting the final bits of 96/128 bit softfloat - posted [RFC PATCH 0/8] fpu: experimental conversion of float128_addsub Message-Id: <20201020163738.27700-1-alex.bennee(a)linaro.org> - partial reviewed [RFC PATCH 00/15] softfloat: alternate conversion of float128_addsub Message-Id: <20201021045149.1582203-1-richard.henderson(a)linaro.org> - posted [PATCH v1 0/6] testing/next (gitdm, acceptance, docker, gitlab) Message-Id: <20201021163136.27324-5-alex.bennee(a)linaro.org> Other ===== - reclaiming space for my gmail (98.5% used!) Completed Reviews [1/1] ======================= [PATCH 0/2] tcg: optimize across branches Message-Id: <20201013222330.173525-1-richard.henderson(a)linaro.org> Absences ======== - Welsh lockdown next week - Children at home Current Review Queue ==================== * [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> * [PATCH v6 0/5] Enable plugin support on msys2/mingw Message-Id: <20201013002806.1447-1-luoyonggang(a)gmail.com> Added: <2020-10-13 Tue> * [PATCH v7 0/4] Improve cirrus msys2 Message-Id: <20201012233740.190-1-luoyonggang(a)gmail.com> Added: <2020-10-13 Tue> * [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com> Added: <2020-09-23 Wed> -- Alex Bennée

5 years, 5 months

[ACTIVITY] 19-23 October 2020

by Christophe Lyon

* 2 days off == Progress == * GCC upstream validation: - identified several regressions, but they had already been reported * GCC - PR96767: no feedback - PR96770: no feedback - patch for C++ thunks with -mpure-code and cortex-m0: handling further feedback - Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: no feedback * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. No progress this week. * infra: - debugging issues with our docker containers == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

5 years, 5 months

Toolchain for cross compiling

by Suresh Nulu

Hi, I am new to toolchains. I would like to know information on building toolchains for different architectures. My objective is to build a cross compiling toolchain for AARCH64 BE target on the RHEL7.6 build system. It would be great if you can give me pointers on how to compile toolchains. Do we have any Wiki pages on building linaro toolchains for different architectures? Appreciate your help. Regards Suresh

5 years, 5 months

[ACTIVITY] 12-16 October 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions - committed minor cleanup fixes - fixed broken trunk build with gcc-4.8 * GCC - PR96767: no feedback - PR96770: no feedback - patch for C++ thunks with -mpure-code and cortex-m0: sent updated patch - Neon intrinsics: sent patch to implement vceqq, vceqz and vceqzq for p64. * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. No progress this week. * infra: - debugging issues with our docker containers == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

5 years, 5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain