- linaro-toolchain - lists.linaro.org

[ACTIVITY] week ending Jan. 31 2021

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - some prep for next weeks TSC QEMU Device and Machine Models ([QEMU-418]) =========================================== - added a bunch of new cards for ARMv8.7 features using ARMs new feature type QEMU Support for Xen ([STR-20]) =============================== - latest iteration of [PATCH V6 00/24] IOREQ feature (+ virtio-mmio) on Arm Message-Id: <1611884932-1851-1-git-send-email-olekstysh(a)gmail.com> - while re-basing [my Xen loader and fixes tree] - realised that [PATCH v4 00/12] Support disabling TCG on ARM (part 2) Message-Id: <20200929224355.1224017-1-philmd(a)redhat.com> would be useful - which awaits [PATCH v14 00/22] i386 cleanup PART 2 Message-Id: <20210128092814.8676-1-cfontana(a)suse.de> being merged [STR-20] <https://projects.linaro.org/browse/STR-20> [my Xen loader and fixes tree] <https://github.com/stsquad/qemu/tree/xen/guest-loader-and-arm-build-cleanup…> QEMU Upstream Work ([UM-2]) =========================== - posted [PATCH v1 0/2] meson fixups for check-tcg/softfloat Message-Id: <20210126145356.7860-1-alex.bennee(a)linaro.org> - posted some documentation patches while helping LKFT team get up and running - [PATCH] docs/system: document an example vexpress-a15 invocation Message-Id: <20210128185300.2875-1-alex.bennee(a)linaro.org> [UM-2] <https://projects.linaro.org/browse/UM-2> Completed Reviews [3/3] ======================= [PATCH v4 0/4] meson: Try to clarify TCG / TCI options for new users Message-Id: <8f1f2dc6-5ad2-7d48-c2f9-9afa1e4d4065(a)weilnetz.de> [PATCH 00/23] TCI fixes and cleanups Message-Id: <20210128082331.196801-1-richard.henderson(a)linaro.org> [PATCH] accel/tcg: Add URL of clang bug to comment about our workaround Message-Id: <20210129130330.30820-1-peter.maydell(a)linaro.org> Absences ======== - Lockdown 3: Home schooling returns! Current Review Queue ==================== * [PATCH V6 00/24] IOREQ feature (+ virtio-mmio) on Arm Message-Id: <1611884932-1851-1-git-send-email-olekstysh(a)gmail.com> Added: <2021-01-29 Fri> * [RFC PATCH 0/4] hw/intc: enable GICv4 memory layout for GICv3 driver Message-Id: <20210124025306.3949-1-leif(a)nuviainc.com> Added: <2021-01-25 Mon> * [PATCH v3 00/21] target-arm: Implement ARMv8.5-MemTag, user mode Message-Id: <20210115224645.1196742-1-richard.henderson(a)linaro.org> Added: <2021-01-18 Mon> * [PATCHv3 00/17] ARMv8.4 Secure EL2 Message-Id: <3333301.iIbC2pHGDl(a)basile.remlab.net> Added: <2020-12-08 Tue> -- Alex Bennée

4 years, 6 months

1
0
0 0

[ACTIVITY] 25-29 January 2021

by Christophe Lyon

== Progress == * GCC upstream validation: - not really catching up, now ~10 days late due to the numerous commits * GCC - Neon intrinsics: vceqzq improvement (PR98730) commited - MVE autovectorization: vorn patch submitted - opened PR98891 about Neon vectorization regression * infra: - reviewed patches. - ABE's make-check-gcc is currently broken == Next == * MVE auto-vectorization/intrinsics improvements * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

4 years, 6 months

1
0
0 0

[ACTIVITY] report week ending 29 Jan

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] + usual upstream maintenance, code review, etc * QEMU-364 [QEMU support for ARMv8.1-M extensions] + CMSDK Clock changes now upstream + When integrating those with the SSE timer model, found what seem like some more clock API changes we could use; patches in progress Some Arm-internal training and similar admin tasks this week. thanks -- PMM

4 years, 6 months

1
0
0 0

[ACTIVITY] week ending 24 Jan 2021

by Richard Henderson

[UM-61 TCG Maint] 3 different attempts at fixing the out-of-temps failure produced by the tcg-constant patch set. The last, longjmp to restart w/ a smaller tb, seems unlikely to have unanticipated side effects. [UM-2 QEMU Maint] Refresh two patches toward cortex-a76. Misc patch review. Partial fix for target/ppc mis-use of tb->flags. r~

4 years, 7 months

1
0
0 0

[ACTIVITY] week ending Jan. 24 2021

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - posted Project Stratos planning priorities for the next development cycle (-> Oct2021) Message-Id: <87im7rtpyq.fsf(a)linaro.org> - baring feedback from members during voting I think this is what we are doing - attended [AGL discussion] on zero-copy for virtio-gpu with Peter Griffin - more meetings on other collaboration opportunities, drew more slide ware - bootstrapped my RB5 rig, just need to figure out how to update the kernel [STR-9] <https://projects.linaro.org/browse/STR-9> [AGL discussion] <https://confluence.automotivelinux.org/display/VE/Meeting+Agenda?src=contex…> QEMU Device and Machine Models ([QEMU-418]) =========================================== - flurry of syncing and card creation, solidified [QEMU-414] [QEMU-418] <https://projects.linaro.org/browse/QEMU-418> [QEMU-414] <https://projects.linaro.org/browse/QEMU-414> QEMU Support for Xen ([STR-20]) =============================== - continued looking at [PATCH V4 00/24] IOREQ feature (+ virtio-mmio) on Arm Message-Id: <1610488352-18494-1-git-send-email-olekstysh(a)gmail.com> [STR-20] <https://projects.linaro.org/browse/STR-20> QEMU Upstream Work ([UM-2]) =========================== - respun [PULL v2 00/30] testing, gdbstub and semihosting Message-Id: <20210118111745.20104-1-alex.bennee(a)linaro.org> to fix NetBSD issue - posted [PATCH v1 0/6] testing/next (docker binfmt tests) Message-Id: <20210119175208.763-1-alex.bennee(a)linaro.org> - posted [PATCH v2 0/8] testing/next (docker, binfmt, gdb version) Message-Id: <20210122181854.23105-1-alex.bennee(a)linaro.org> [UM-2] <https://projects.linaro.org/browse/UM-2> Completed Reviews [4/4] ======================= [PATCH] util/log: flush TB cache when log level changes Message-Id: <161130982491.1038646.15688151175539344664.stgit@pasha-ThinkPad-X280> [PATCH v3] hw/core/qdev-properties-system: Rewrite set_pci_host_devaddr using GLib Message-Id: <20201125083300.861206-1-philmd(a)redhat.com> [RFC PATCH] tests/docker: Allow passing --network option when building images Message-Id: <20210119054502.531451-1-f4bug(a)amsat.org> [PATCH] tcg: Increase the static number of temporaries Message-Id: <20210121025439.1120405-1-richard.henderson(a)linaro.org> Absences ======== - Lockdown 3: Home schooling returns! Current Review Queue ==================== * [PATCH v3 00/21] target-arm: Implement ARMv8.5-MemTag, user mode Message-Id: <20210115224645.1196742-1-richard.henderson(a)linaro.org> Added: <2021-01-18 Mon> * [PATCH 0/6] accel: Restrict TCG-specific code Message-Id: <20210117164813.4101761-1-f4bug(a)amsat.org> Added: <2021-01-18 Mon> * [PATCH V4 00/24] IOREQ feature (+ virtio-mmio) on Arm Message-Id: <1610488352-18494-1-git-send-email-olekstysh(a)gmail.com> Added: <2021-01-13 Wed> * [PATCH v5 00/23] tcg: Better handling of constants Message-Id: <20201217145215.534637-1-richard.henderson(a)linaro.org> Added: <2020-12-17 Thu> -- Alex Bennée

4 years, 7 months

1
0
0 0

[ACTIVITY] 18-22 January 2021

by Christophe Lyon

== Progress == * GCC upstream validation: - catching up, still ~1 week late due to the numerous commits * GCC - Neon intrinsics: looking at vceqzq improvement (PR98730) - MVE autovectorization: WIP on vorn and vcmp. - helping with cortex-m0 libgcc patch validation. Opened PR98779 about issues in libgcc wrt -mpure-code. * infra: - reviewed patches. - ABE's make-check-gcc is currently broken == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE auto-vectorization/intrinsics improvements

4 years, 7 months

1
0
0 0

[ACTIVITY] report week ending 22 Jan

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] + Code review (including RTH's MTE-for-user-mode-emulation) + Investigating an intermittent failure of a test case involving an s390 guest on aarch64 hosts... * QEMU-364 [QEMU support for ARMv8.1-M extensions] + Converted the ARMSSE (IoTKit/SSE-200) code over to use the Clock framework, which was added to QEMU after ARMSSE was first written. (This is a prereq for adding the new-in-SSE-300 timer device, which will use Clocks.) Sent the patches out for review. I'm currently experimenting with a schedule of: Mon: JIRA task work; Tue: code review; Thu: JIRA task work; Fri: misc upstream thanks -- PMM

4 years, 7 months

1
0
0 0

[ACTIVITY] week ending 17 Jan 2021

by Richard Henderson

[UM-61 TCG Maint] Refresh tcg backend constraints. Pull request for tcg constants. -- which caused reported failures. [UM-2 QEMU Maint] Refresh sve pred_desc fixes. Refresh arm alignment fixes. Misc review. [QEMU-344 ARMv8.5-MemTag] Refresh mte user-only patch set. r~

4 years, 7 months

1
0
0 0

Re: Compilation issue with Linaro ARM toolchain

by Mathieu Poirier

Adding the Linaro toolchain group mailing list. On Mon, Jan 18, 2021 at 05:49:39PM +0300, Sergey Suloev wrote: > Hi, guys, > > I am having an issue builduing kernel 5.11 (rc4) with Linaro ARM toolchain. > The issue seems to be related to CC plugins sources. > Here is my build log: https://pastebin.com/DTn7Szax. I have never seen this > before with versions 5.10 and below. > > Thank you, > Sergey > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4 years, 7 months

3
2
0 0

[ACTIVITY] 11-15 January 2021

by Christophe Lyon

== Progress == * GCC upstream validation: - catching up, still ~1 week late due to the numerous commits * GCC - Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: committed - MVE autovectorization: movmisalign, vshl and vshr: committed. WIP on next operators. - opened 2 PRs about missed optims related to these recent patches - helping with cortex-m0 libgcc patch validation * infra: - reviewed ABE patches. - fixed abe-tests == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE auto-vectorization/intrinsics improvements

4 years, 7 months

1
0
0 0

[ACTIVITY] week ending Jan. 17 2021

by Alex Bennée

QEMU Device and Machine Models ([QEMU-418]) =========================================== - flurry of syncing and card creation, solidified [QEMU-414] [QEMU-414] <https://projects.linaro.org/browse/QEMU-414> VirtIO Initiative ([STR-9]) =========================== - discussion about next cycle, call on Monday [STR-9] <https://projects.linaro.org/browse/STR-9> QEMU Support for Xen ([STR-20]) =============================== - started looking at [PATCH V4 00/24] IOREQ feature (+ virtio-mmio) on Arm Message-Id: <1610488352-18494-1-git-send-email-olekstysh(a)gmail.com> [STR-20] <https://projects.linaro.org/browse/STR-20> QEMU Upstream Work ([UM-2]) =========================== - posted [PATCH v1 0/9] testing/next (tags!, more travis/shippable deprecation) Message-Id: <20210113151408.27939-1-alex.bennee(a)linaro.org> - posted [PATCH v2 00/12] testing/next (tags!, shippable/travis deprecation, regression fixes, checkpatch) Message-Id: <20210114165730.31607-1-alex.bennee(a)linaro.org> - posted [PULL 00/30] testing, gdbstub and semihosting Message-Id: <20210115130828.23968-1-alex.bennee(a)linaro.org> - looks like a NetBSD regression needs to be looked at [UM-2] <https://projects.linaro.org/browse/UM-2> Completed Reviews [1/1] ======================= Re: [PATCH v6 34/35] Auto-import Docker support files Message-Id: <1610080146-14968-1-git-send-email-tsimpson(a)quicinc.com> Absences ======== - Lockdown 3: Home schooling returns! Current Review Queue ==================== * [PATCH V4 00/24] IOREQ feature (+ virtio-mmio) on Arm Message-Id: <1610488352-18494-1-git-send-email-olekstysh(a)gmail.com> Added: <2021-01-13 Wed> * [PATCH v5 00/23] tcg: Better handling of constants Message-Id: <20201217145215.534637-1-richard.henderson(a)linaro.org> Added: <2020-12-17 Thu> * [PATCHv3 00/17] ARMv8.4 Secure EL2 Message-Id: <3333301.iIbC2pHGDl(a)basile.remlab.net> Added: <2020-12-08 Tue> * [PATCH v2 0/7] xen/arm: Unbreak ACPI Message-Id: <20201023154156.6593-1-julien(a)xen.org> Added: <2020-10-24 Sat> -- Alex Bennée

4 years, 7 months

1
0
0 0

[ACTIVITY] report week ending 15 Jan

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] + code review, pullreq + fixed the "breaks a gitlab CI run" issue with the 'merge docs into a single sphinx manual' patch * QEMU-364 [QEMU support for ARMv8.1-M extensions] + Progress with the SSE-300 model: - finished model of new timer device - updated iotkit-sysctl register block with SSE-300 specific behaviour - implemented simple dummy model of new CPU<N>_PWRCTRL register block - made sse-300 code more data-driven so it can handle sse-300 putting some of the devices at different places thanks -- PMM

4 years, 7 months

1
0
0 0

[ACTIVITY] week ending Jan. 10 2021

by Alex Bennée

QEMU Device and Machine Models ([QEMU-418]) =========================================== - pinged tsc/tle about scheduling a call for next week [QEMU-418] <https://projects.linaro.org/browse/QEMU-418> QEMU Upstream Work ([UM-2]) =========================== - flushed gdbstub and semihosting queues - sent pre-PR series to list [UM-2] <https://projects.linaro.org/browse/UM-2> Completed Reviews [2/2] ======================= [PATCH V1] gdbstub: suspended state support Message-Id: <1609963815-417989-1-git-send-email-steven.sistare(a)oracle.com> [PATCH] gdbstub.c uses incorrect check for active gdb in use_gdb_syscalls Message-Id: <20201223212752.1145294-1-keithp(a)keithp.com> Absences ======== - Lockdown 3: Home schooling returns! Current Review Queue ==================== * [PATCH v5 00/23] tcg: Better handling of constants Message-Id: <20201217145215.534637-1-richard.henderson(a)linaro.org> Added: <2020-12-17 Thu> * [PATCHv3 00/17] ARMv8.4 Secure EL2 Message-Id: <3333301.iIbC2pHGDl(a)basile.remlab.net> Added: <2020-12-08 Tue> * [PATCH v2 0/7] xen/arm: Unbreak ACPI Message-Id: <20201023154156.6593-1-julien(a)xen.org> Added: <2020-10-24 Sat> * [PATCH v6 0/5] Enable plugin support on msys2/mingw Message-Id: <20201013002806.1447-1-luoyonggang(a)gmail.com> Added: <2020-10-13 Tue> -- Alex Bennée

4 years, 7 months

1
0
0 0

[ACTIVITY] 4-8 January 2021

by Christophe Lyon

== Progress == * GCC upstream validation: - restarted validation after e/o year maintenance - catching up, no regression to report so far * GCC - Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: no feedback - MVE autovectorization: movmisalign accepted, waiting for boostrap results vshl and vshr: pinged. - helping with cortex-m0 libgcc patch validation * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. No progress this week. * infra: - reviewed ABE patches == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE auto-vectorization/intrinsics improvements

4 years, 7 months

1
0
0 0

[ACTIVITY] report week ending 8 Jan

by Peter Maydell

Progress (2 day week this week): * UM-2 [QEMU upstream maintainership] + Unsurprisingly, pretty much just catching up with email, pull requests, code review, bug reports, respins of patchsets... * QEMU-364 [QEMU support for ARMv8.1-M extensions] + The final parts of base v8.1M and Cortex-M55 support are now in master. thanks -- PMM

4 years, 7 months

1
0
0 0

[ACTIVITY] 2 weeks ending 27 Dec 2020

by Richard Henderson

(or the 10 days preceding Christmas) [UM-61 TCG Maint] New version of tcg constants patch set. TCG backend constraints cleanup. ARM NEON host patch set. [UM-2 QEMU Maint] Fixed tcg gvec bug vs hosts without vector support. Rebase and re-send pauth impdef algorithm. Patch review: mips, riscv. gdbstub. r~

4 years, 8 months

1
0
0 0

[ACTIVITY] week ending Dec. 20 2020

by Alex Bennée

VirtIO RPMB ([STR-5]) ===================== - Continued working on Rust port of vhost-user-rpmb - Re-based and updated the [QEMU based branch] [QEMU based branch] <https://github.com/stsquad/qemu/tree/virtio/vhost-user-rpmb-v2> QEMU Support for Xen ([STR-20]) =============================== - re-based and continued to work on Xen development environment - with my [current branch] I can now boot domU inside dom0 - also can now run qemu-aarch64 as a Dom0 PV backend [branch to clean-up and add "virt" machine] <https://github.com/stsquad/qemu/tree/xen/add-xen-virt-machine> [current branch] <https://github.com/stsquad/qemu/tree/xen/guest-loader-and-arm-build-cleanup…> QEMU Device and Machine Models ([QEMU-418]) =========================================== - created new initiative for tracking work both in and outside group - we don't want another watchdog duplication - worked on refining definition for [CPU model for QEMU] - wrote to Linaro open discussion list to canvas members requirements Message-Id: <878saesi0x.fsf(a)linaro.org> [QEMU-418] <https://projects.linaro.org/browse/QEMU-418> [CPU model for QEMU] <https://projects.linaro.org/browse/QEMU-414> QEMU Upstream Work ([UM-2]) =========================== - posted [RFC PATCH] configure: add --without-default-features Message-Id: <20201202153827.17446-1-alex.bennee(a)linaro.org> - posted [PATCH v2 0/8] testing/next (without-features, gitlab, python) Message-Id: <20201210190417.31673-1-alex.bennee(a)linaro.org> - posted [PATCH v1 0/6] gdbstub (auxv, tests, cleanup) Message-Id: <20201214153012.12723-6-alex.bennee(a)linaro.org> - posted [PULL 00/11] testing and configure updates Message-Id: <20201216164827.24457-1-alex.bennee(a)linaro.org> - posted [PULL v2 00/11] testing and configure updates Message-Id: <20201217094330.17400-1-alex.bennee(a)linaro.org> - still stalled due to some stale build issues (unable to repro) - posted [PATCH v2 0/9] gdbstub/next (cleanups, softmmu, SVE) Message-Id: <20201218112707.28348-1-alex.bennee(a)linaro.org> [UM-2] <https://projects.linaro.org/browse/UM-2> Other work ========== - bootstrapped gitdm metadata for GCC project - planning for Stratos/QEMU Next Cycle - declared bankruptcy on my review queue, flushed most of it Completed Reviews [5/5] ======================= [PATCH v4 00/11] hvf: Implement Apple Silicon Support Message-Id: <20201203234857.21051-2-agraf(a)csgraf.de> [RFC v9 00/22] i386 cleanup Message-Id: <20201208194839.31305-1-cfontana(a)suse.de> [PATCH 0/3] hw/arm: sabrelite: Improve emulation fidelity to allow booting upstream U-Boot Message-Id: <1607937538-69471-1-git-send-email-bmeng.cn(a)gmail.com> [PATCH 0/2] Fix test-char reference counting bug Message-Id: <20201215224133.3545901-1-ehabkost(a)redhat.com> [PATCH 0/8] Add RISC-V semihosting 0.2. Finish ARM semihosting 2.0 Message-Id: <20201125213617.2496935-1-keithp(a)keithp.com> Absences ======== - Back on Jan 5th, Happy Christmas Current Review Queue ==================== * [PATCH v5 00/23] tcg: Better handling of constants Message-Id: <20201217145215.534637-1-richard.henderson(a)linaro.org> Added: <2020-12-17 Thu> * [PATCHv3 00/17] ARMv8.4 Secure EL2 Message-Id: <3333301.iIbC2pHGDl(a)basile.remlab.net> Added: <2020-12-08 Tue> * [PATCH v2 0/7] xen/arm: Unbreak ACPI Message-Id: <20201023154156.6593-1-julien(a)xen.org> Added: <2020-10-24 Sat> * [PATCH v6 0/5] Enable plugin support on msys2/mingw Message-Id: <20201013002806.1447-1-luoyonggang(a)gmail.com> Added: <2020-10-13 Tue> -- Alex Bennée

4 years, 8 months

1
0
0 0

[ACTIVITY] 14-18 December 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions/new failures, trunk build broken several times * GCC - Neon intrinsics: vceqq, vceqz and vceqzq for p64 patch: no feedback - MVE autovectorization: committed veor, vbic, vmvn and vneg. Sent movmisalign, vshl and vshr patches. * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. No progress this week. * infra: - reviewed ABE patches == Next == Holidays until Jan 4th, 2021 == Future == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE auto-vectorization/intrinsics improvements

4 years, 8 months

1
0
0 0

[ACTIVITY] 7 - 11 Dec 2020

by Prathamesh Kulkarni

== This Week == * PR97872 (missed optimization for comparison on vectors) - Committed fix to trunk * PR97903 (Lower a & b != 0 to vtst) - In progress * PR66791 (Replace builtins by vector extensions in arm_neon.h intrinsics) - Committed patches for vmvn - Patches approved for vcreate, vneg, vclt, vcgt. == Next Week == - PR97903 - PR66791: Commit approved patches and work on new intrinsics

4 years, 8 months

1
0
0 0

perf issue: etm traces are dumped to the wrong AUX buffer

by Zied Guermazi

hi I am using perf syscall to collect etm traces for btraces implementation in GDB running on Linux kernel 5.9.1 on a cortex A7. in this test case, I am debugging a multi-threaded process (2 pthreads). For each thread, GDB is calling the sys call perf_event_open and gives the corresponding thread ptid.lwp as argument. for each syscall, the AUX buffer is mmap(ped) to a dedicated memory. this is working for almost all test cases I have, except this one, where it has 50% failure rate when executed manually. 90% failure rate when executed from a script. the source code for debugged program is listed below. /* This testcase is part of GDB, the GNU debugger. Copyright 2013-2019 Free Software Foundation, Inc. Contributed by Intel Corp. <markus.t.metzger(a)intel.com> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ #include <pthread.h> static pthread_barrier_t barrier; static int global; static void * test(void *arg) { pthread_barrier_wait(&barrier); global= 42; /* bp.1 */ pthread_barrier_wait(&barrier); global= 42; /* bp.2 */ return arg; } int main (void) { pthread_t th; pthread_barrier_init(&barrier, NULL, 2); pthread_create(&th, NULL, test, NULL); test(NULL); pthread_join(th, NULL); pthread_barrier_destroy(&barrier); return 0; /* bp.3 */ } in this test case, a breakpoint is set at the line containing the comment /* bp.1 */ , and we start collecting traces. a second breakpoint is set at the line containing the comment /* bp.2 */, and we analyze collected traces. in a successful testcase we get both threads traces in dedicated buffers thread 1 [Switching to thread 1 (Thread 0xb6ff9ca0 (LWP 8813))] #0test (arg=0x0) at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:34 34 global = 42; /* bp.2 */ (gdb) info record Active record target: record-btrace Recording format: arm Processor CoreSight ETM Trace. Buffer size: 8kB. Recorded 126 instructions in 15 functions (0 gaps) for thread 1 (Thread 0xb6ff9ca0 (LWP 8813)). (gdb) record function-call-history /ilc 1 test inst 1,9 at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:30,32 2 pthread_barrier_wait@plt inst 10,12 at 3 pthread_barrier_wait inst 13,32 at 4 __aeabi_uidivmod inst 33,36 at 5 __udivsi3 inst 37,39 at 6 __udivsi3 inst 40,48 at 7 __aeabi_uidivmod inst 49,52 at 8 pthread_barrier_wait inst 53,77 at 9 __libc_do_syscall inst 78,80 at 10 pthread_barrier_wait inst 81,102 at 11 __aeabi_uidivmod inst 103,106 at 12 __udivsi3 inst 107,109 at 13 __udivsi3 inst 110,118 at 14 __aeabi_uidivmod inst 119,122 at 15 pthread_barrier_wait inst 123,126 at here is a log of the collected trace generic elements cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_NO_SYNC 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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_EXCEPTION thread 2 [Switching to thread 2 (Thread 0xb6ea7460 (LWP 8816))] #0test (arg=0x0) at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:34 34 global = 42; /* bp.2 */ (gdb) info record Active record target: record-btrace Recording format: arm Processor CoreSight ETM Trace. Buffer size: 8kB. Recorded 150 instructions in 20 functions (0 gaps) for thread 2 (Thread 0xb6ea7460 (LWP 8816)). (gdb) record function-call-history /ilc 1 test inst 1,9 at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:30,32 2 pthread_barrier_wait@plt inst 10,12 at 3 pthread_barrier_wait inst 13,32 at 4 __aeabi_uidivmod inst 33,36 at 5 __udivsi3 inst 37,39 at 6 __udivsi3 inst 40,48 at 7 __aeabi_uidivmod inst 49,52 at 8 pthread_barrier_wait inst 53,66 at 9 __aeabi_uidivmod inst 67,70 at 10 __udivsi3 inst 71,73 at 11 __udivsi3 inst 74,82 at 12 __aeabi_uidivmod inst 83,86 at 13 pthread_barrier_wait inst 87,103 at 14 __libc_do_syscall inst 104,106 at 15 pthread_barrier_wait inst 107,126 at 16 __aeabi_uidivmod inst 127,130 at 17 __udivsi3 inst 131,133 at 18 __udivsi3 inst 134,142 at 19 __aeabi_uidivmod inst 143,146 at 20 pthread_barrier_wait inst 147,150 at here is a log of the collected trace generic elements cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_NO_SYNC 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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_EXCEPTION in the failing test we got all traces in one buffer, the second one is empty (gdb) thread 1 [Switching to thread 1 (Thread 0xb6ff9ca0 (LWP 8826))] #0 test (arg=0x0) at /home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:34 34 global = 42; /* bp.2 */ (gdb) info record Active record target: record-btrace Recording format: arm Processor CoreSight ETM Trace. Buffer size: 8kB. Recorded 276 instructions in 36 functions (0 gaps) for thread 1 (Thread 0xb6ff9ca0 (LWP 8826)). (gdb) record function-call-history /ilc 1 1 test inst 1,9 at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:30,32 2 pthread_barrier_wait@plt inst 10,12 at 3 pthread_barrier_wait inst 13,32 at 4 __aeabi_uidivmod inst 33,36 at 5 __udivsi3 inst 37,39 at 6 __udivsi3 inst 40,48 at 7 __aeabi_uidivmod inst 49,52 at 8 pthread_barrier_wait inst 53,77 at 9 __libc_do_syscall inst 78,80 at 10 test inst 81,88 at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:30,32 11 pthread_barrier_wait@plt inst 89,91 at 12 pthread_barrier_wait inst 92,111 at 13 __aeabi_uidivmod inst 112,115 at 14 __udivsi3 inst 116,118 at 15 __udivsi3 inst 119,127 at 16 __aeabi_uidivmod inst 128,131 at 17 pthread_barrier_wait inst 132,145 at 18 __aeabi_uidivmod inst 146,149 at 19 __udivsi3 inst 150,152 at 20 __udivsi3 inst 153,161 at 21 __aeabi_uidivmod inst 162,165 at 22 pthread_barrier_wait inst 166,182 at 23 __libc_do_syscall inst 183,185 at 24 pthread_barrier_wait inst 186,205 at 25 __aeabi_uidivmod inst 206,209 at 26 __udivsi3 inst 210,212 at 27 __udivsi3 inst 213,221 at 28 __aeabi_uidivmod inst 222,225 at 29 pthread_barrier_wait inst 226,229 at 30 test inst 230,230 at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:34 31 pthread_barrier_wait inst 231,252 at 32 __aeabi_uidivmod inst 253,256 at 33 __udivsi3 inst 257,259 at 34 __udivsi3 inst 260,268 at 35 __aeabi_uidivmod inst 269,272 at 36 pthread_barrier_wait inst 273,276 at here is a log of the collected trace generic elements cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_NO_SYNC 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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_EXCEPTION cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_NO_SYNC 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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_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 --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE --->cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_EXCEPTION (gdb) thread 2 [Switching to thread 2 (Thread 0xb6ea7460 (LWP 8827))] #0test (arg=0x0) at/home/ubuntu/development/gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.btrace/multi-thread-step.c:34 34 global = 42; /* bp.2 */ (gdb) info record Active record target: record-btrace Recording format: arm Processor CoreSight ETM Trace. Buffer size: 8kB. Recorded 0 instructions in 0 functions (0 gaps) for thread 2 (Thread 0xb6ea7460 (LWP 8827)). (gdb) record function-call-history /ilc 1 No trace. (gdb) is there any known issues for calling perf_event_open twice for two different threads? is there any known issues for flushing traces when a switch between two threads takes place? is there any known issue for tracing threads when switching happens due to a pthread_barrier_wait? do you have any other hint to provide here? Kind regards Zied Guermazi

4 years, 8 months

1
0
0 0

[ACTIVITY] week ending 13 Dec 2020

by Richard Henderson

[UM-2] New revision on arm alignment patch set. Patch review: mips and i386 cleanups. [UM-61] New revision on splitwx patch set. r~

4 years, 8 months

1
0
0 0

[ACTIVITY] report week ending 11 Dec

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] + sent out a pullreq for 6.0, and did a bunch more patch review + sent out a respin of the "build one manual, not five" RFC I sent last month; nobody objected to the RFC so this time around it is a proper PATCH + had a brief scan through the GIC architecture specification to look at what extra GICv4 and GICv4.1 add (the big thing is that the ITS is now mandatory; QEMU doesn't emulate that yet) * VIRT-364 [QEMU support for ARMv8.1-M extensions] + SSE-300 timer device model more or less functionally-complete (though untested). I ran into some issues with QEMU's Clock APIs that I needed to fix in the process -- sent a patchseries trying to address those. + Got most of the outstanding v8.1M patches into master; sent a small patch series with respins of the last 4 or so patches that needed more work thanks -- PMM

4 years, 8 months

1
0
0 0

[ACTIVITY] 7-11 December 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: committed vand and vorr patches. Sent updated versions of veor, vbic and vmvn. vshr and vshl need some refactorization with Neon versions, clarified the best way to go with Arm maintainers. - PR97875 (suboptimal vectorization on MVE): investigation shows that movmisalign patterns are missing for MVE. * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. No progress this week. * infra: - debugging issues with our docker containers - looking at ABE patches * misc: - provided feedback to Arm's partner wrt Intrinsics documentation == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE auto-vectorization/intrinsics improvements

4 years, 8 months

1
0
0 0

[ACTIVITY] week ending 6 Dec 2020

by Richard Henderson

[UM-59] More work on softfloat rem; f128 still needs work. [UM-2] Patch review, notably v8.1m, mips cleanups, arc port. Revisions to arm alignment patch set. r~

4 years, 8 months

1
0
0 0

[ACTIVITY] 30 November-4 December 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: handling feedback on(vand, vorr, veor, vshr, vshl). WIP vmvn, vbic. Found further vectorization issues. * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. * infra: - debugging issues with our docker containers - looking at ABE patches == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

4 years, 8 months

1
0
0 0

[ACTIVITY] 30 Nov - 4 Dec 2020

by Prathamesh Kulkarni

== This Week == * PR97872 (missed optimization on less-than vector comparison) - Upstream discussion with Richard, patch close to being approved. - Causes a regression for pr78102.c. * PR66791 (replace builtins by vector extensions in arm_neon.h intrinsics) - Submitted patches for vmvn, vcreate, vneg. - Kyrill approved patch for vmvn, and asked to remove corresponding builtins from being created in backend. == Next Week == - Hopefully commit fix for PR97872 - Continue with PR66791 - Start looking at another vectorization PR

4 years, 8 months

1
0
0 0

Timeout tests timing out

by David Blaikie

The clang-cmake-armv8-lld (linaro-toolchain owners) buildbot is timing out trying to run some timeout tests (Dan Liew author): Pass: http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/5672 Fail: http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/5673 Is there anything we can do to the buildbot? Or the tests? (bump up the time limits or maybe remove the tests as unreliable?)

4 years, 8 months

5
14
0 0

[ACTIVITY] week ending Dec. 6 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - started reviewing latest EPAM IOREQ/VirtIO patches Message-Id: <1606732298-22107-1-git-send-email-olekstysh(a)gmail.com> VirtIO RPMB ([STR-5]) ===================== - Continued working on Rust port of vhost-user-rpmb VirtIO Portability Demo ([STR-13]) ================================== - done and closed QEMU Support for Xen ([STR-20]) =============================== - re-based and continued to work on Xen development environment - with my [current branch] I can now boot domU inside dom0 - also can now run qemu-aarch64 as a Dom0 PV backend [current branch] <https://github.com/stsquad/qemu/tree/xen/guest-loader-and-arm-build-cleanup…> QEMU Device and Machine Models ([QEMU-418]) =========================================== - created new initiative for tracking work both in and outside group - we don't want another watchdog duplication - worked on refining definition for [CPU model for QEMU] - wrote to Linaro open discussion list to canvas members requirements Message-Id: <878saesi0x.fsf(a)linaro.org> [CPU model for QEMU] <https://projects.linaro.org/browse/QEMU-414> QEMU Upstream Work ([UM-2]) =========================== - posted [RFC PATCH] configure: add --without-default-features Message-Id: <20201202153827.17446-1-alex.bennee(a)linaro.org> Other work ========== - bootstrapped gitdm metadata for GCC project Completed Reviews [1/1] ======================= [PATCH v4 00/11] hvf: Implement Apple Silicon Support Message-Id: <20201203234857.21051-2-agraf(a)csgraf.de> -- Alex Bennée

4 years, 8 months

1
0
0 0

[ACTIVITY] report week ending 3 Dec

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] + Cut down the patch review queue a bit ready for 6.0 development cycle * VIRT-364 [QEMU support for ARMv8.1-M extensions] + started working on modelling of the SSE-300. Have done some of the easy "ID registers are different" stuff and started on modelling a new timer device that isn't in the SSE-200. thanks -- PMM

4 years, 8 months

1
0
0 0

[ACTIVITY] 23 - 27 Nov 2020

by Prathamesh Kulkarni

== This Week == * PR66791 (Replace __builtins_* in arm_neon.h intrinsics by C vector extensions) - Submitted patch for vmvn, waiting for feedback. - Created and tested patches for vcreate and vneg. * PR97849 (segfault in ifcvt with -march=armv8.2-a+sve) - Committed fix to trunk. == Next Week == - PR97872 - Continue with PR66791

4 years, 8 months

1
0
0 0

[ACTIVITY] week ending Nov. 29 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - Raised [STR-21] to cover some Zephyr work - Synced with EPAM and ARM to discuss their work and direction [STR-21] <https://projects.linaro.org/browse/STR-21> VirtIO RPMB ([STR-5]) ===================== - Started investigating Rust port of vhost-user-rpmb [STR-5] <https://projects.linaro.org/browse/STR-5> VirtIO Portability Demo ([STR-13]) ================================== - delivered gold copy for talk at [OSS and ALS Japan 2020] - synced with ALS guys on talk [OSS and ALS Japan 2020] <https://sched.co/f2Yk> QEMU Upstream Work ([UM-2]) =========================== - posted [PATCH v1 for 5.1 00/10] various fixes (CI, Xen, plugins) Message-Id: <20201110192316.26397-1-alex.bennee(a)linaro.org> - posted [[PULL for 5.2-rc3 0/7] various CI cleanups (scripts, avocado, gitlab)] [UM-2] <https://projects.linaro.org/browse/UM-2> [[PULL for 5.2-rc3 0/7] various CI cleanups (scripts, avocado, gitlab)] <mu4e:i:20201123112518.13425-1-alex.bennee@linaro.org> Completed Reviews [4/4] ======================= [for-5.2 0/9] docs: Move orphan top-level .rst files into manuals Message-Id: <20201112144041.32278-1-peter.maydell(a)linaro.org> [PATCH v3 00/41] Mirror map JIT memory for TCG Message-Id: <20201106032921.600200-1-richard.henderson(a)linaro.org> - CLOSING NOTE [2020-11-14 Sat 11:52] Had a brief look over, waiting for next revision Added: <2020-11-06 Fri> [PATCH v2 00/13] Remove GCC < 4.8 checks Message-Id: <20201126112915.525285-1-marcandre.lureau(a)redhat.com> [PATCH] gdbstub: Correct misparsing of vCont C/S requests Message-Id: <20201121210342.10089-1-peter.maydell(a)linaro.org> Absences ======== - Illness Current Review Queue ==================== * [PATCH v2 0/4] linux/sparc: more get/set_context fixes Message-Id: <20201106152738.26026-1-peter.maydell(a)linaro.org> Added: <2020-11-06 Fri> * [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> -- Alex Bennée

4 years, 9 months

1
0
0 0

[ACTIVITY] 23-27 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: sent a few patches (vand, vorr, veor, vshr, vshl). WIP vmvn, vbic * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. * infra: - debugging issues with our docker containers - looking at ABE patches == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements Reply Forward

4 years, 9 months

1
0
0 0

[ACTIVITY] report week ending 27 Nov

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] + Cut rc3; there were a few last-minute bugfixes that came in so we will need an rc4 * VIRT-364 [QEMU support for ARMv8.1-M extensions] + read through the SSE-300 TRM and identified the required work to model it (it's similar to the SSE-200 which we already have but with various minor changes and a couple of new devices) * wisdom tooth extracted \o/ thanks -- PMM

4 years, 9 months

1
0
0 0

[ACTIVITY] week ending 22 Nov 2020

by Richard Henderson

[UM-59 # FPU Emulation Maintainership ] Lots more work converting to FloatParts. Almost all floatx80 now converted. Still to do are log2 and rem/mod for full conversion. r~

4 years, 9 months

1
0
0 0

[ACTIVITY] 16-20 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: more patterns updates (vshl, vshr). WIP * 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, 9 months

1
0
0 0

[ACTIVITY] report week ending 20 Nov

by Peter Maydell

Generally productive week rather derailed at the end by a sudden onset of toothache Thursday night :-/ Progress: * UM-2 [QEMU upstream maintainership] + usual release cycle work * VIRT-364 [QEMU support for ARMv8.1-M extensions] + Worked through the remaining set of identified new features for v8.1M implementing them. + Fixed a handful of pre-existing bugs along the way. + Sent out a patchset with all this plus the "Implement (no-MVE) Cortex-M55 model" patch on top, since we now have all the pieces needed for it. + The next and final piece of work here is to implement a model of a board that uses the Cortex-M55. -- PMM

4 years, 9 months

1
0
0 0

[ACTIVITY] week ending Nov. 15 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== VirtIO Portability Demo ([STR-13]) ================================== - recorded AGL demo videos (KVM, TCG Xen Dom0 with and without Xen aware kernel) - recorded [preview version of talk] [STR-13] <https://projects.linaro.org/browse/STR-13> [preview version of talk] <https://fileserver.linaro.org/s/wgt2AAj9rxYqJop> QEMU Upstream Work ([UM-2]) =========================== - posted [PATCH v1 for 5.1 00/10] various fixes (CI, Xen, plugins) Message-Id: <20201110192316.26397-1-alex.bennee(a)linaro.org> [UM-2] <https://projects.linaro.org/browse/UM-2> Completed Reviews [2/2] ======================= [for-5.2 0/9] docs: Move orphan top-level .rst files into manuals Message-Id: <20201112144041.32278-1-peter.maydell(a)linaro.org> [PATCH v3 00/41] Mirror map JIT memory for TCG Message-Id: <20201106032921.600200-1-richard.henderson(a)linaro.org> - CLOSING NOTE [2020-11-14 Sat 11:52] Had a brief look over, waiting for next revision Added: <2020-11-06 Fri> Current Review Queue ==================== * [PATCH v2 0/4] linux/sparc: more get/set_context fixes Message-Id: <20201106152738.26026-1-peter.maydell(a)linaro.org> Added: <2020-11-06 Fri> * [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> -- Alex Bennée

4 years, 9 months

1
0
0 0

[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, 9 months

1
0
0 0

[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, 9 months

1
0
0 0

[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, 9 months

1
0
0 0

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, 9 months

1
0
0 0

[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, 9 months

1
0
0 0

[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, 9 months

1
0
0 0

[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, 9 months

1
0
0 0

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, 9 months

1
0
0 0

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, 9 months

2
1
0 0

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, 9 months

2
1
0 0

[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

4 years, 9 months

1
0
0 0

[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

4 years, 9 months

1
0
0 0

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

by Galina Kistanova

4 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain