- linaro-toolchain - lists.linaro.org

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, 10 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, 10 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, 10 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, 10 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 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, 12 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, 12 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, 12 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, 12 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, 12 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, 12 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

5 years

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

5 years

1
0
0 0

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

by Galina Kistanova

5 years

2
1
0 0

[ACTIVITY] 26-30 October 2020

by Christophe Lyon

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

5 years

1
0
0 0

[ACTIVITY] week ending 25 Oct 2020

by Richard Henderson

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

5 years

1
0
0 0

[ACTIVITY] week ending Oct. 25 2020

by Alex Bennée

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

5 years

1
0
0 0

[ACTIVITY] 19-23 October 2020

by Christophe Lyon

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

5 years

1
0
0 0

Toolchain for cross compiling

by Suresh Nulu

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

5 years

2
1
0 0

[ACTIVITY] 12-16 October 2020

by Christophe Lyon

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

5 years

1
0
0 0

[ACTIVITY] week ending 11 Oct 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] Completed capstone update. Flushed tcg patch queue. Fixed a decodetree issue for pmm. [VIRT-339 # ARMv8.5-BTI, Branch Target Identification ] Refreshed BTI linux-user patch set. [VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ] Fixed a couple of MTE bugs reported by Arm. r~

5 years

1
0
0 0

[ACTIVITY] week ending Oct. 11 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== VirtIO Portability Demo ([STR-13]) ================================== - sync up discussion - posted [RFC PATCH 0/4] generic loader FDT support (for direct Xen boot) Message-Id: <20201009170742.23695-1-alex.bennee(a)linaro.org> - now GICv3 and GICv2 boot fine under TCG, pointing finger at EFI/Grub [STR-13] <https://projects.linaro.org/browse/STR-13> Upstream Work ([QEMU-109]) ========================== - posted [PATCH v1 00/22] testing and plugin fixes with gitdm updates (pre PR) Message-Id: <20201007160038.26953-1-alex.bennee(a)linaro.org> - posted [PULL 00/22] acceptance regressions, testing, gitdm, plugins Message-Id: <20201009163147.28512-1-alex.bennee(a)linaro.org> Other ===== - spent some time on JIRA cleanup for PoR - preparation for TSC health check call Completed Reviews [3/3] ======================= [PATCH v3 0/6] Enable plugin support on msys2/mingw Message-Id: <20201001163429.1348-1-luoyonggang(a)gmail.com> - CLOSING NOTE [2020-10-06 Tue 12:37] A few rough edges but seems to be on track, merged first few patches. Added: <2020-10-01 Thu> [PATCH 00/12] contrib/gitdm: First round of updates Message-Id: <20201006160653.2391972-1-f4bug(a)amsat.org> - CLOSING NOTE [2020-10-10 Sat 17:00] Merged Added: <2020-10-06 Tue> [PATCH 0/2] .mailmap: Fixes since v5.1 Message-Id: <20201004172644.2027440-1-f4bug(a)amsat.org> - CLOSING NOTE [2020-10-10 Sat 17:00] Merged Added: <2020-10-04 Sun> Absences ======== Current Review Queue ==================== * [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com> Added: <2020-09-23 Wed> * [RFC PATCH 0/3] Automatically convert configure options to meson build options Message-Id: <20200913100534.22084-1-pbonzini(a)redhat.com> Added: <2020-09-13 Sun> * [PATCH 0/6] misc: Some inclusive terminology changes Message-Id: <20200910070131.435543-1-philmd(a)redhat.com> Added: <2020-09-10 Thu> * [PATCH 00/43] tcg patch queue Message-Id: <20200909001647.532249-1-richard.henderson(a)linaro.org> Added: <2020-09-09 Wed> -- Alex Bennée

5 years

1
0
0 0

[ACTIVITY] report week ending 9 Oct

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + another round of code review and target-arm queue wrangling + found and fixed an edge-case bug in setting Q flag in SMLAD insn + fixed a GICv3 emulation bug where we didn't ever raise maintenance interrupts * VIRT-364 [QEMU support for ARMv8.1-M extensions] + went through Arm ARM and identified exactly what the "v8.1M changes which aren't part of a named architectural feature" are (for QEMU-409 subtask) + implemented some parts of NOCP handling that were left as TODO comments for being v8.1M-specific + implemented conditional-select insns (CSEL, CSINC, CSINV, CSNEG) + implemented low-overhead-loops and branch-future (in the 'trivial' don't-cache-anything way the architecture permits) thanks -- PMM

5 years

1
0
0 0

[ACTIVITY] 5-9 October 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions - committed minor cleanup fixes - reduced the number of gcc-testresults emails to avoid too much traffic * GCC - PR96767: no feedback - PR96770: no feedback - patch for C++ thunks with -mpure-code and cortex-m0: received comments, handling - PR96914 MVE intrinsics: committed patches to remove a few illegal ones and add the missing ones. * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues. No progress this week. == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

5 years

1
0
0 0

[ACTIVITY] 21 September - 2 October 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions - committed minor cleanup fixes - improved gcc-testresults email titles after discussion with other contributors * GCC - PR96767: patch sent - PR96770: patch sent - sent another patch to fix C++ thunks with -mpure-code and cortex-m0 - PR94595: patch committed - looking at some problems with validating with PCH disabled * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * MVE intrinsics improvements

5 years

1
0
0 0

[ACTIVITY] week ending Oct. 4 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== VirtIO RPMB ([STR-5]) ===================== - some discussion about eMMC pass-through [STR-5] <https://projects.linaro.org/browse/STR-5> VirtIO Portability Demo ([STR-13]) ================================== - more debugging and tweaking for Xen - rooting out ACPI and DT issues - got working on QEMU TCG (with GICv2) - testing Grub patches for MachiatoBin - see state on MB Message-Id: <01000174ea0b72ae-028e8625-0ead-4cb8-a429-49bd11b5bf30-000000(a)email.amazonses.com> and state on TCG Message-Id: <87tuvcn067.fsf(a)linaro.org> - verified sound and KVM working on MachatioBin [STR-13] <https://projects.linaro.org/browse/STR-13> Upstream Work ([QEMU-109]) ========================== - posted [PULL 00/14] testing updates (python, plugins) Message-Id: <20201002113645.17693-1-alex.bennee(a)linaro.org> [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> [various fixes] <https://github.com/stsquad/qemu/tree/testing/next> Completed Reviews [1/1] ======================= [PATCH v6 00/14] Reverse debugging Message-Id: <160137726426.31007.12061315974029139983.stgit@pasha-ThinkPad-X280> Current Review Queue ==================== * [PATCH v3 0/6] Enable plugin support on msys2/mingw Message-Id: <20201001163429.1348-1-luoyonggang(a)gmail.com> Added: <2020-10-01 Thu> * [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com> Added: <2020-09-23 Wed> -- Alex Bennée

5 years, 1 month

1
0
0 0

[ACTIVITY] week ending 28 Sep 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] Capstone patch set v4. Implement float128_muladd. Some patch review. Note, on holiday next week. r~

5 years, 1 month

1
0
0 0

[ACTIVITY] week ending Sep. 27 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== VirtIO RPMB ([STR-5]) ===================== - posted [RFC PATCH 00/19] vhost-user-rpmb (Replay Protected Memory Block) Message-Id: <20200925125147.26943-1-alex.bennee(a)linaro.org> Upstream Work ([QEMU-109]) ========================== - posted [PATCH v1 00/15] testing/next pre-PR (python3.6, check-tcg) Message-Id: <20200925154027.12672-1-alex.bennee(a)linaro.org> - posted [PATCH] configure: make building deprecated targets easier Message-Id: <20200925161408.4016-1-alex.bennee(a)linaro.org> [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> [various fixes] <https://github.com/stsquad/qemu/tree/testing/next> Completed Reviews [1/1] ======================= [PATCH v4 00/11] capstone + disassembler patches Message-Id: <20200921174118.39352-1-richard.henderson(a)linaro.org> Absences ======== - Connect (virtual) Current Review Queue ==================== * [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com> Added: <2020-09-23 Wed> * [PATCH v4 00/15] Reverse debugging Message-Id: <160006358590.31457.16757371597343007847.stgit@pasha-ThinkPad-X280> Added: <2020-09-18 Fri> * [RFC PATCH 0/3] Automatically convert configure options to meson build options Message-Id: <20200913100534.22084-1-pbonzini(a)redhat.com> Added: <2020-09-13 Sun> * [PATCH 0/6] misc: Some inclusive terminology changes Message-Id: <20200910070131.435543-1-philmd(a)redhat.com> Added: <2020-09-10 Thu> -- Alex Bennée

5 years, 1 month

1
0
0 0

[ACTIVITY] report week ending 25 Sep

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + Got a v6 series sent to the list of the conversion of QAPI doc-comments into rST/Sphinx. This took most of the week, following Markus' detailed review on the v5 (and involved some wrestling with Meson). Optimistic that this can get into master now... thanks -- PMM

5 years, 1 month

1
0
0 0

[ACTIVITY] week ending 20 Sep 2020

by Richard Henderson

[VIRT-349 # QEMU SVE2 Support ] Posted v3, now tested vs armie. [VIRT-327 # Richard's upstream QEMU work ] Another round of capstone patches, still needs review. r~

5 years, 1 month

1
0
0 0

[ACTIVITY] week ending Sep. 20 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - started reviewing [PATCH 00/11] Additional virtio device resources Message-Id: <20200824143708.5664-6-ndragazis(a)arrikto.com> - synced with Arnd and JPB on VirtIO work for [minimal memory profile stuff] [STR-9] <https://projects.linaro.org/browse/STR-9> [minimal memory profile stuff] <https://projects.linaro.org/browse/STR-8> VirtIO RPMB ([STR-5]) ===================== - worked with Illias to get him up and running with uboot virtio-rpmb driver - debugging differences in HMAC implementations :-/ [STR-5] <https://projects.linaro.org/browse/STR-5> VirtIO Portability Demo ([STR-13]) ================================== - continue to debug nouvaue issues on latest kernel - need to ESC/reset to EFI until framebuffer comes on - seems ok with Debian 5.6.14-2~bpo10+1 - but not vanilla 5.6.14 or above - need to track down kernel differences - did some poking into getting Xen up on Debian - seems multiboot not the way, got a bit further but need a debug build [STR-13] <https://projects.linaro.org/browse/STR-13> Upstream Work ([QEMU-109]) ========================== - posted [PATCH v1 0/6] deprecation and linux-user tweaks (+test fix) Message-Id: <20200914150716.10501-5-alex.bennee(a)linaro.org> - posted [PATCH v2 0/8] configure deprecation, linux-user and iotest fixes Message-Id: <20200915134317.11110-1-alex.bennee(a)linaro.org> - posted [PULL 0/8] configure deprecation, linux-user and test fix Message-Id: <20200916122648.17468-1-alex.bennee(a)linaro.org> [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> Completed Reviews [2/2] ======================= [RISU PATCH 0/2] arm.risu: two minor fixes Message-Id: <20200901162046.32670-1-peter.maydell(a)linaro.org> [PATCH V3 00/10] fix some comment spelling errors Message-Id: <20200917075029.313-1-zhaolichang(a)huawei.com> Absences ======== - Family self-isolated for first half of week Current Review Queue ==================== * [PATCH v4 00/15] Reverse debugging Message-Id: <160006358590.31457.16757371597343007847.stgit@pasha-ThinkPad-X280> Added: <2020-09-18 Fri> * [RFC PATCH 0/3] Automatically convert configure options to meson build options Message-Id: <20200913100534.22084-1-pbonzini(a)redhat.com> Added: <2020-09-13 Sun> * [PATCH 0/6] misc: Some inclusive terminology changes Message-Id: <20200910070131.435543-1-philmd(a)redhat.com> Added: <2020-09-10 Thu> * [PATCH 00/43] tcg patch queue Message-Id: <20200909001647.532249-1-richard.henderson(a)linaro.org> Added: <2020-09-09 Wed> -- Alex Bennée

5 years, 1 month

1
0
0 0

[ACTIVITY] report week ending 18 Sep

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + usual maintainer stuff + started a rebase/respin of the convert-QAPI-docs-to-Sphinx series * VIRT-364 [QEMU support for ARMv8.1-M extensions] + sent patchset to make QEMU handle the way M-profile and A-profile report presence of fp16 differently in their ID registers thanks -- PMM

5 years, 1 month

1
0
0 0

[ACTIVITY] 14-18 September 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions - committed minor cleanup fixes * GCC - PR96767: patch almost ready - PR71233: missing ACLE intrinsics, updated the list. Created PR96914 with the missing MVE intrinsics * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 1 month

1
0
0 0

[ACTIVITY] week ending 14 Sep 2020

by Richard Henderson

[ Sorry it's a bit late. ] [VIRT-327 # Richard's upstream QEMU work ] Send out tcg patch queue. Prototype a disassembler using llvm. Not ideal. If we proceed with this further, we should probably schedule time for it, because the job is not small. Updating the capstone submodule; a couple of rounds converting that to meson. r~

5 years, 1 month

1
0
0 0

[ACTIVITY] 7 - 11 September 2020

by Prathamesh Kulkarni

== This Week == * GNU-659 (calculix) - Comparing code-gen of hoisting region doesn't show many more extra stores - Came up with two heuristics, which "fix" the issue, but aren't very general. * LLVM-611 - D79785: Created fix for expensive checks issue, and posted on llvm-dev - D87430: Posted patch for adding heuristic to LowerCall. == Next Week == - Continue ongoing tasks

5 years, 1 month

1
0
0 0

libcxx-libcxxabi-libunwind-armv7-linux-noexceptions broken

by Louis Dionne

Hi, Something appears to be wrong with your builder libcxx-libcxxabi-libunwind-armv7-linux-noexceptions: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux-no… It's been failing that way for over 2 weeks now. Is anyone monitoring those builders? Louis

5 years, 1 month

1
0
0 0

linaro-tk1-03

by Galina Kistanova

Hello Linaro Toolchain Working Group, Do you plan to bring linaro-tk1-03 back online soon? If not, I'll remove it from the LLVM buildbot this Friday. Thanks Galina

5 years, 1 month

2
1
0 0

[ACTIVITY] week ending 6 Sep 2020

by Richard Henderson

[VIRT-349 # QEMU SVE2 Support ] Continuing the testing vs armie. [VIRT-327 # Richard's upstream QEMU work ] * More microblaze cleanup, including a check-acceptance regression fix from the first pull. Ho hum. * Patch review, queue is empty again. * Old patch queue cleanup, Fixed some gvec bugs affecting 32-bit x86; testing vs aa32 risu. r~

5 years, 1 month

1
0
0 0

[ACTIVITY] #1 August-4 September 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions - committed testcase fixes * GCC - PR96768: switch tables for thumb-1 with -mpure-code. Patch sent, discussion on-going - PR96769: fix committed. - PR71233: missing ACLE intrinsics, updated the list. Created PR96914 with the missing MVE intrinsics * benchmarking: - Scripts to run coremark on stm32 now merged, debugging issues == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 1 month

1
0
0 0

[ACTIVITY] 31 August - 4 September 2020

by Prathamesh Kulkarni

== This Week == * GNU-659 (calculix LTO regression) - Gathered perf stats for various opt levels and posted on ML * LLVM-611 (tune blx lowering heuristic) - Dave Green committed my patch which had to be reverted due to build-bot failure with expensive checks turned on. - Posted analysis of the issue upstream * Misc - Committed patch to add --strict option to bmk-scripts/spec2xxx-config. == Next Week == - Continue ongoing tasks

5 years, 1 month

1
0
0 0

[ACTIVITY] week ending Sep. 6 2020

by Alex Bennée

VirtIO Initiative ([STR-9]) =========================== - bunch of sync-up calls and catch-ups - potential Connect fireside chat/podcast thing - Project Stratos call [STR-9] <https://projects.linaro.org/browse/STR-9> VirtIO Portability Demo ([STR-13]) ================================== - successful surgery on PCI has resulted in EFI FB display - for some reason nouveau not kicking in, PCIe seems absent [STR-13] <https://projects.linaro.org/browse/STR-13> Upstream Work ([QEMU-109]) ========================== - pulling together [various fixes] for post-meson build - posted [PATCH v1 0/8] some testing and CI updates (re-greening) Message-Id: <20200903112107.27367-4-alex.bennee(a)linaro.org> - posted [PATCH v1 0/4] current plugins/next (reorg + hwprofile) Message-Id: <20200904134007.4175-1-alex.bennee(a)linaro.org> - posted [RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation Message-Id: <20200904165140.10962-1-alex.bennee(a)linaro.org> [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> [various fixes] <https://github.com/stsquad/qemu/tree/testing/next> Other stuff =========== - TSC and PoR prep and calls Completed Reviews [2/2] ======================= [PATCH 0/2] crypto: fix build with gcrypt Message-Id: <0a1a8958-691f-d16d-2f6b-6392e6a20966(a)linaro.org> [PATCH v6 00/16] QEMU cpus.c refactoring part2 Message-Id: <20200901072201.7133-3-cfontana(a)suse.de> Current Review Queue ==================== * [PATCH v7 00/16] QEMU cpus.c refactoring part2 Message-Id: <20200903105614.17772-1-cfontana(a)suse.de> Added: <2020-09-04 Fri> * [PATCH v3 00/15] Reverse debugging Message-Id: <159903454714.28509.7439453309116734374.stgit@pasha-ThinkPad-X280> Added: <2020-09-03 Thu> * [kvm-unit-tests PATCH v2 00/10] Add support for generic ELF cross-compiler Message-Id: <20200901085056.33391-1-r.bolshakov(a)yadro.com> Added: <2020-09-02 Wed> * [virtio-dev] [PATCH v3 0/6] Add virtio-iommu built-in topology Message-Id: <20200821131540.2801801-1-jean-philippe(a)linaro.org> Added: <2020-09-02 Wed> -- Alex Bennée

5 years, 1 month

1
0
0 0

[ACTIVITY] report week ending 4 Sep

by Peter Maydell

Progress: (short week, three days) * VIRT-65 [QEMU upstream maintainership] + sent patches to remove QEMU's support for KVM on AArch32 hosts (which we deprecated when the kernel removed its end of the support) * VIRT-364 [QEMU support for ARMv8.1-M extensions] + fp16 work is now in master + sent patches to add support for mps2-an386 and mps2-an500 boards (Cortex-M4 and Cortex-M7 setups similar to the existing mps2-an385 Cortex-M3 board model) thanks -- PMM

5 years, 1 month

1
0
0 0

[ACTIVITY] 2 weeks ending 30 Aug 2020

by Richard Henderson

[VIRT-349 # QEMU SVE2 Support ] Rebased on accepted patches, a few bits of cleanup per review. [VIRT-327 # Richard's upstream QEMU work ] Patch review: * mttcg for microblaze * aa32 vfp fp16 * aa32 neon fp16 * hexagon v3 * riscv vector v4 Posted microblaze conversion to translator + decodetree. Posted v2 of crypto/cipher cleanup. Posted pr for softfloat. r~

5 years, 2 months

1
0
0 0

[ACTIVITY] 24 - 28 August 2020

by Prathamesh Kulkarni

== This Week == * GNU-659 (LTO calculix regression) - Started upstream discussion * LLVM-611 (Tune lowering heuristic to blx for code size) - Addressing upstream feedback for patch to fold tLDRpci, tBLx -> tBL in foldMemoryOperand hook - Added new heuristic to ISel, for follow up patch. * LLVM-639 (Better idiom for comparing 32-bit values on arm) - Started working on patch == Next Week == - Continue ongoing tasks

5 years, 2 months

1
0
0 0

[ACTIVITY] 24-28 August 2020

by Christophe Lyon

1 day off == Progress == * GCC upstream validation: - reported several regressions - committed testcase fixes * GCC - patch for PR94758 (-mpurecode and cortex-m23) applied to thunk/gcc-10/gcc-9. Bug closed, but opened several others to track performance improvements with -mpurecode - PR96768: switch tables for thumb-1 with -mpure-code. Patch sent, discussion on-going - PR96769: WIP - PR71233: missing ACLE intrinsics. I will first have to update the list * benchmarking: - Scripts to run coremark on stm32 now merged, working on using them in production * misc: - infra patches/reviews - internal support, leading to GCC testsuite cleanups for cortex-m == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 2 months

1
0
0 0

[ACTIVITY] report week ending 28 Aug

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + Just the usual code review and pull request work. * VIRT-364 [QEMU support for ARMv8.1-M extensions] + I have all fp16 insns (both VFP and Neon) implemented now, and the VFP patches have been reviewed. Just need to track down a few last test failures and then I can send the Neon patches out for review. thanks -- PMM

5 years, 2 months

1
0
0 0

[ACTIVITY] 17-21 August 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported several regressions - committed testcase fixes * GCC - sent patch for PR94758 (-mpurecode and cortex-m23) * benchmarking: - Scripts to run coremark on stm32 now merged, working on using them in production * misc: - infra patches/reviews == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 2 months

1
0
0 0

[ACTIVITY] report week ending 21 Aug

by Peter Maydell

Progress (short week, 2 days): * VIRT-65 [QEMU upstream maintainership] + We got 5.1 out the door. I think this is the first release in the many years I've been handling them where we managed to avoid needing an rc4. + Spent a fair amount of time helping Paolo to debug his conversion of the QEMU build system to Meson. We managed to land that today. + First of the KVM Forum programme committee meetings * VIRT-364 [QEMU support for ARMv8.1-M extensions] + More progress with fp16 support work; another handful of insns done. thanks -- PMM

5 years, 2 months

1
0
0 0

[ACTIVITY] week ending 16 Aug 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] Patch review, all over the place. Patches for pauth impdef algorithm. Patches for mte WnR bit. Patches for crypto/cipher cleanup. [VIRT-349 # QEMU SVE2 Support ] Split out 20 patches from the SVE2 patch set. r~

5 years, 2 months

1
0
0 0

[ACTIVITY] 10-14 August 2020

by Christophe Lyon

- 2 half days off == Progress == * GCC upstream validation: - reported several regressions (trunk and release branches) - committed 2 testcase fixes * GCC - resumed work on PR94758 (-mpurecode and cortex-m23). Patch almost ready * benchmarking: - Scripts to run coremark on stm32 now merged, working on using them in production * misc: - infra patches/reviews == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 2 months

1
0
0 0

[ACTIVITY] week ending Aug. 16 2020

by Alex Bennée

VirtIO RPMB ([STR-5]) ===================== - got program_key and get_write_counter implemented - finally making progress, the rest "should" be easy ;-) [STR-5] <https://projects.linaro.org/browse/STR-5> [testing kernel] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/test…> [qemu tree] <https://github.com/stsquad/qemu/tree/virtio/vhost-user-rpmb> VirtIO Portability Demo ([STR-13]) ================================== - spent some time getting the MachiatoBin up and running - system now working with latest 5.8 kernel and KVM support confirmed - still debugging Xen setup, will return to this when back from holidays - currently no graphics available - need to perform [minor surgery] on the PCI bus [STR-13] <https://projects.linaro.org/browse/STR-13> [minor surgery] <http://wiki.macchiatobin.net/tiki-index.php?page=MACCHIATObin+%28up+to+rev+…> Upstream Work ([QEMU-109]) ========================== - posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id: <20200701135652.1366-1-alex.bennee(a)linaro.org> : done - posted [PULL 00/16] various fixes for rc2 (semihosting, tcg, docker, tests/vm) Message-Id: <20200727122357.31263-1-alex.bennee(a)linaro.org> - a little leadership committee review [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> Completed Reviews [2/2] ======================= [PATCH RFC 00/10] fix some comment spelling errors Message-Id: <20200812101500.2066-1-zhaolichang(a)huawei.com> [PATCH 0/2] target/arm: Implement an IMPDEF pauth algorithm Message-Id: <2219f3f9-7894-f898-0cad-43eccaa2a70d(a)linaro.org> Absences ======== - short week - holiday 13th-28th Aug - see you in September Current Review Queue ==================== * [PATCH] plugins: new syscalls plugin Message-Id: <20200812115816.4454-1-matthias(a)weckbecker.name> Added: <2020-08-12 Wed> * [PATCH v2 00/14] Reverse debugging Message-Id: <159714365354.18946.2967871683340522027.stgit@pasha-ThinkPad-X280> Added: <2020-08-11 Tue> * [PATCH 00/11] Run cross-compilation build tests in the gitlab-CI Message-Id: <20200804170055.2851-1-thuth(a)redhat.com> Added: <2020-08-04 Tue> * [RFC v3 0/8] QEMU cpus.c refactoring part2 Message-Id: <20200803090533.7410-1-cfontana(a)suse.de> Added: <2020-08-03 Mon> -- Alex Bennée

5 years, 2 months

1
0
0 0

[ACTIVITY] 27 July- 7 August 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported a few regressions / minor testcase fix * benchmarking: - Created the Jenkins job to run coremark on stm32 (added/updated scripts for that) * misc: - infra patches/reviews == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 2 months

1
0
0 0

Please make lldb-aarch64-ubuntu non-flaky, or stop it from sending email / irc pings

by Nico Weber

I got an email and an irc ping for http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/6924 My change has no relation to the test failure. Flaky bots aren't allowed to send email or ping, so either make it non-flaky or make it not send stuff. Thanks, Nico

5 years, 2 months

3
2
0 0

[ACTIVITY] two weeks ending 9 Aug 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] Patch review -- lots of riscv vector stuff. Fix for PAUTH error indication. Diagnosed an MTE KASAN problem -- my theory is a guest os thread error. Investigation into PAUTH slowdown. r~

5 years, 2 months

2
1
0 0

[ACTIVITY] week ending Aug. 9 2020

by Alex Bennée

Realised I missed last week so bumper update. VirtIO Initiative ([STR-9]) =========================== - Inter-VM device emulation (call on Mon 20th July 2020) Message-Id: <20200715112342.GD18817(a)stefanha-x1.localdomain> - posted [RFC PATCH v1 0/3] put arm64 kvm_config on a diet Message-Id: <20200804124417.27102-1-alex.bennee(a)linaro.org> - EGL Call - saw an interesting breakdown from other team doing vhost-user - OpenSynergy - got a good idea of where they are heading and the various players [STR-9] <https://projects.linaro.org/browse/STR-9> VirtIO RPMB ([STR-5]) ===================== - got the return path working - re-based my [testing kernel] and made more spec conforming tweaks [STR-5] <https://projects.linaro.org/browse/STR-5> [simplified testing branch] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…> [kernel] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…> [testing kernel] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/test…> VirtIO Portability Demo ([STR-13]) ================================== - spent some time getting the MachiatoBin up and running [STR-13] <https://projects.linaro.org/browse/STR-13> Upstream Work ([QEMU-109]) ========================== - posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id: <20200701135652.1366-1-alex.bennee(a)linaro.org> : done - Debugging a failure on m68k with pgd_find_hole_fallback - seems 4.17+ with no /proc leave mmap_min_addr = 0 and NOREPLACE hits it - rth pondering a fix, may get back to it on Monday - More debugging of icount bug, looks like -icount sleep=off interacts with [bug 1859021] - posted [PULL 00/16] various fixes for rc2 (semihosting, tcg, docker, tests/vm) Message-Id: <20200727122357.31263-1-alex.bennee(a)linaro.org> [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> [bug 1859021] <https://bugs.launchpad.net/qemu/+bug/1859021> Completed Reviews [6/6] ======================= [PATCH v2 0/2] linux-user: fix clock_nanosleep() Message-Id: <20200722174612.2917566-1-laurent(a)vivier.eu> - CLOSING NOTE [2020-07-24 Fri 21:47] Queued to my tree Added: <2020-07-22 Wed> [PATCH v1 0/3] python/qemu: follow-up changes for ConsoleSocket Message-Id: <20200717203041.9867-1-robert.foley(a)linaro.org> - CLOSING NOTE [2020-07-24 Fri 21:47] Queued to my tree Added: <2020-07-18 Sat> [virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type Message-Id: <20200518203721.7625-1-ndragazis(a)arrikto.com> - CLOSING NOTE [2020-07-24 Fri 21:48] Interesting stuff, sent a few terminology fixes Added: <2020-07-15 Wed> [PATCH v2] cputlb: Make store_helper less fragile to compiler optimizations Message-Id: <20200724195128.2373212-1-scw(a)google.com> [PATCH 0/4] Refactor get_fpstatus_ptr() ready for AArch32 fp16 Message-Id: <20200806104453.30393-1-peter.maydell(a)linaro.org> [DRAFT PATCH 000/143] Meson integration for 5.2 Message-Id: <1596741379-12902-1-git-send-email-pbonzini(a)redhat.com> Absences ======== - 2 days off sick - "holiday" 13th-25th Aug Current Review Queue ==================== * [PATCH 00/11] Run cross-compilation build tests in the gitlab-CI Message-Id: <20200804170055.2851-1-thuth(a)redhat.com> Added: <2020-08-04 Tue> * [RFC v3 0/8] QEMU cpus.c refactoring part2 Message-Id: <20200803090533.7410-1-cfontana(a)suse.de> Added: <2020-08-03 Mon> * [PATCH 0/2] accel/tcg: remove implied BQL from cpu_handle_interrupt/exception path Message-Id: <20200731125127.30866-1-robert.foley(a)linaro.org> Added: <2020-07-31 Fri> * [PATCH 0/3] float16 APIs and alternative sNaN handling Message-Id: <1596102747-20226-1-git-send-email-chihmin.chao(a)sifive.com> Added: <2020-07-30 Thu> -- Alex Bennée

5 years, 2 months

1
0
0 0

[ACTIVITY] report week ending 7 Aug

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + rc3 sent out. Optimistically hoping for release next week. + rebased the patchset converting QAPI doc-comments to rST + Fixed a bug in syndrome register values for copro insns trapped from AArch32 to AArch64 * VIRT-364 [QEMU support for ARMv8.1-M extensions] + Finished and sent out the patchset that cleans up the coproc insn decode and corrects the NOCP handling + With assistance from RTH, figured out how to use gvec helpers to implement fp16 for various Neon insns. Added fp16 support to 20 or so insns; still have 15 or so to go. thanks -- PMM

5 years, 2 months

1
0
0 0

[ACTIVITY] report week ending 31 Jul

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + More release herding... + Sent fixes for some bugs: - assertion in the imx_epit timer device when guest soft-reset it - netduino2/netduinoplus2 forgot to configure system clock scale so using SysTick in "run at CPU frequency" mode would hang - most M-profile boards failed to make AIRCR.SYSRESETREQ actually reset the system * VIRT-364 [QEMU support for ARMv8.1-M extensions] + More progress with fp16: all the VFP insns now handled, including the new-for-fp16 ones. Still to do: all of Neon... + Spent some time working through the details of NOCP vs UNDEF in the M-profile coprocessor space for the various revisions of the architecture. v8.1M adjusts things a bit in this area and I want to clean up this bit of QEMU's current code and get the v8.1M bits right. Fact: next Monday (3rd August) will be the 10th anniversary of my secondment into Linaro! -- PMM

5 years, 3 months

1
0
0 0

[ACTIVITY] week ending 26 Jul 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] Misc patch review. - Largest bit is half of riscv 0.9 vector patch set. Fix arm E2 bug in ptw_translate. Fix arm E3 buts in direct kernel startup. Fix linux-user chroot failure. r~

5 years, 3 months

1
0
0 0

[ACTIVITY] week ending Jul. 26 2020

by Alex Bennée

VirtIO Related Work ([STR-9]) ============================= - Inter-VM device emulation (call on Mon 20th July 2020) Message-Id: <20200715112342.GD18817(a)stefanha-x1.localdomain> - AGL and OpenSynergy calls - posted [PATCH v2 0/7] doc build updates and terminology definitions Message-Id: <20200724154251.12546-1-alex.bennee(a)linaro.org> [STR-9] <https://projects.linaro.org/browse/STR-9> VirtIO RPMB ([STR-5]) - trying to work out why return path not working [STR-5] <https://projects.linaro.org/browse/STR-5> [simplified testing branch] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…> [kernel] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…> Upstream Work ([QEMU-109]) ========================== - posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id: <20200701135652.1366-1-alex.bennee(a)linaro.org> : done - posted [PATCH v2 00/12] candidate fixes for 5.1-rc1 (testing, semihosting, OOM tcg, x86 fpu) Message-Id: <87wo2vu6lg.fsf(a)linaro.org> - posted [PATCH v3 00/16] candidate fixes for 5.1-rc1 (testing, semihosting, OOM tcg, x86 fpu) Message-Id: <20200724064509.331-1-alex.bennee(a)linaro.org> - Debugging a failure on m68k with pgd_find_hole_fallback - seems 4.17+ with no /proc leave mmap_min_addr = 0 and NOREPLACE hits it - rth pondering a fix, may get back to it on Monday - Another icount bug, looks like -icount sleep=off interacts with [bug 1859021] [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> [bug 1859021] <https://bugs.launchpad.net/qemu/+bug/1859021> Blog Post ([LBO-34]) ==================== - after a few fixes to fix gplus links the [article is now live] [article is now live] <https://www.linaro.org/blog/the-evolution-of-the-qemu-translator/> Completed Reviews [1/1] ======================= [PATCH v2 0/2] linux-user: fix clock_nanosleep() Message-Id: <20200722174612.2917566-1-laurent(a)vivier.eu> - CLOSING NOTE [2020-07-24 Fri 21:47] Queued to my tree Added: <2020-07-22 Wed> [PATCH v1 0/3] python/qemu: follow-up changes for ConsoleSocket Message-Id: <20200717203041.9867-1-robert.foley(a)linaro.org> - CLOSING NOTE [2020-07-24 Fri 21:47] Queued to my tree Added: <2020-07-18 Sat> [virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type Message-Id: <20200518203721.7625-1-ndragazis(a)arrikto.com> - CLOSING NOTE [2020-07-24 Fri 21:48] Interesting stuff, sent a few terminology fixes Added: <2020-07-15 Wed> Current Review Queue ==================== * [PATCH v4 00/22] target/xtensa: implement double precision FPU Message-Id: <20200711110655.20287-1-jcmvbkbc(a)gmail.com> Added: <2020-07-13 Mon> * [PATCH v3 00/19] mailmap: Add more entries to sanitize 'git log' output Message-Id: <20200702173818.14651-1-f4bug(a)amsat.org> Added: <2020-07-02 Thu> * [PATCH v3 0/9] memory: assert and define MemoryRegionOps callbacks Message-Id: <20200630122710.1119158-1-ppandit(a)redhat.com> Added: <2020-06-30 Tue> * [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU Message-Id: <cover.1578407802.git.jan.kiszka(a)siemens.com> Added: <2020-04-09 Thu> -- Alex Bennée

5 years, 3 months

1
0
0 0

[ACTIVITY] report week ending 24 Jul

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + Pretty much all release work this week. Some minor bug investigation/fixing. -- PMM

5 years, 3 months

1
0
0 0

[ACTIVITY] week ending 19 Jul 2020

by Richard Henderson

[VIRT-327 # Richard's upstream QEMU work ] Misc patch review. [GCC] I looked into Adhemerval's libgomp-scalability patch set. The code looks good, and I can't see anything wrong. The cancel-parallel-2 test that's reported to regress, does, sometimes. It never fails for me on qemu-test (aarch64, tx1). It *only* fails under the dejagnu test harness on x86_64 and ppc64le. When run by hand it succeeds, always. I cannot explain that at all. I've run the testsuite with OMP_DEBUG_ENV=verbose and see that the dejagnu environment is as expected. Anyway, I can't make forward progress because I can't reproduce the problem under controlled conditions. r~

5 years, 3 months

1
0
0 0

[ACTIVITY] week ending Jul. 19 2020

by Alex Bennée

VirtIO Related Work ([STR-9]) ============================= - putting together a demo system with a MacchiatoBin - idea here Message-Id: <871rlkmzbs.fsf(a)linaro.org> - posted On doorbells (queue notifications) Message-Id: <87r1tdydpz.fsf(a)linaro.org> for discussion on RTT - posted Enhancing virtio-mmio for MSI (new card required?) Message-Id: <alpine.DEB.2.21.2007151407190.4124@sstabellini-ThinkPad-T480s> - started reviewing [virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type Message-Id: <20200518203721.7625-3-ndragazis(a)arrikto.com> - VIRTIO Sync-up call - mainly discussing reducing traps MMIO vs PCIe - need some better figures to justify adding MSI to MMIO [STR-9] <https://projects.linaro.org/browse/STR-9> VirtIO RPMB ([STR-5]) - realised the virtio driver in the [kernel] sent extra frames I wasn't expecting [STR-5] <https://projects.linaro.org/browse/STR-5> [kernel] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…> Upstream Work ([QEMU-109]) ========================== - posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id: <20200701135652.1366-1-alex.bennee(a)linaro.org> : done - posted [PATCH v2 00/11] misc fixes for rc0 (docker, plugins, softfloat) Message-Id: <20200713200415.26214-1-alex.bennee(a)linaro.org> - posted [PULL 0/9] final misc fixes for 5.1-rc0 Message-Id: <20200714095247.19573-1-alex.bennee(a)linaro.org> - took a couple of Message-Id: <20200715105542.14428-1-alex.bennee(a)linaro.org> attempt to finally get merged Message-Id: <20200715111455.19237-1-alex.bennee(a)linaro.org> - posted [PATCH v1 0/5] candidate fixes for 5.1-rc1 (shippable, semihosting, OOM tcg) Message-Id: <20200717105139.25293-1-alex.bennee(a)linaro.org> [QEMU-109] <https://projects.linaro.org/browse/QEMU-109> Blog Post ([LBO-34]) ==================== - finished writing the [evolution of the translator] blogpost, should go up next week [LBO-34] <https://projects.linaro.org/browse/LBO-34> [evolution of the translator] <https://docs.google.com/document/d/190BlYjSTt-nZSR8dNdOxptt-swOZiGnASndEuXo…> Completed Reviews [4/4] ======================= [PATCH for-5.1 0/4] Document virt and a few other Arm boards Message-Id: <20200713175746.5936-1-peter.maydell(a)linaro.org> [PATCH 0/2] python/qemu: follow-up changes for ConsoleSocket Message-Id: <20200715204814.2630-1-robert.foley(a)linaro.org> [PATCH 00/13] Reverse debugging Message-Id: <159316678008.10508.6615172353109944370.stgit@pasha-ThinkPad-X280> Lost patience with more merge failures. [PATCH 0/5] linux-user: Support extended clone(CLONE_VM) Message-Id: <87h7vbyowf.fsf(a)linaro.org> Current Review Queue ==================== * [virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type Message-Id: <20200518203721.7625-1-ndragazis(a)arrikto.com> Added: <2020-07-15 Wed> * [PATCH v4 00/22] target/xtensa: implement double precision FPU Message-Id: <20200711110655.20287-1-jcmvbkbc(a)gmail.com> Added: <2020-07-13 Mon> * [PATCH v3 00/19] mailmap: Add more entries to sanitize 'git log' output Message-Id: <20200702173818.14651-1-f4bug(a)amsat.org> Added: <2020-07-02 Thu> * [PATCH v3 0/9] memory: assert and define MemoryRegionOps callbacks Message-Id: <20200630122710.1119158-1-ppandit(a)redhat.com> Added: <2020-06-30 Tue> -- Alex Bennée

5 years, 3 months

1
0
0 0

[ACTIVITY] report week ending 17 Jul

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + More wrangling of release stuff and unreliable infrastructure. * VIRT-364 [QEMU support for ARMv8.1-M extensions] + Managed to find a few days to put in some more work pushing fp16 handling forwards. I now have implementations of fp16 for most of the VFP insns (still todo: VCVT, VSEL, VMAXNM/VMINNM, VRINT*; then the few insns that are new-for-fp16. Then all of Neon, which is larger.) thanks -- PMM

5 years, 3 months

1
0
0 0

[ACTIVITY] 12 - 17 July 2020

by Diana Picus

== Progress == * More work on Morello * llvm 10.0.1 final hasn't been tagged yet == Plan == * Vacation until early August

5 years, 3 months

1
0
0 0

[ACTIVITY] week ending 12 Jul 2020

by Richard Henderson

[VIRT-339 # ARMv8.5-BTI, Branch Target Identification ] [VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ] Rebase and update linux-user for comments. [VIRT-327 # Richard's upstream QEMU work ] Patch review. r~

5 years, 3 months

1
0
0 0

[ACTIVITY] week ending Jul. 12 2020

by Alex Bennée

VirtIO Related Work ([STR-9]) ============================= - putting together a demo system with a MacchiatoBin - idea here Message-Id: <871rlkmzbs.fsf(a)linaro.org> [STR-9] <https://projects.linaro.org/browse/STR-9> VirtIO RPMB ([VIRT-371]) [VIRT-371] <https://projects.linaro.org/browse/VIRT-371> [simplified testing branch] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…> Upstream Work ([VIRT-109]) ========================== - posted [PATCH v1 00/18] testing/next (vm, gitlab) Message-Id: <9ad1234e-bbb7-9396-21e1-58041cffd847(a)redhat.com> - posted [PATCH v2 00/25] testing/next (vm, gitlab, docker) Message-Id: <20200624140446.15380-1-alex.bennee(a)linaro.org> - posted [PATCH v3 00/30] testing/next (gitlab, vm, docker) Message-Id: <20200626181357.26211-1-alex.bennee(a)linaro.org> - posted [PATCH v4 00/40] testing/next (vm, gitlab, fixes) Message-Id: <20200701135652.1366-1-alex.bennee(a)linaro.org> - posted [PULL 00/41] testing updates (vm, gitlab, misc build fixes) Message-Id: <20200707070858.6622-1-alex.bennee(a)linaro.org> - some failures, working on a v2 (and additional accrued patches) - posted [PATCH v1 00/13] misc rc0 fixes (docs, plugins, docker) Message-Id: <20200709141327.14631-1-alex.bennee(a)linaro.org> [VIRT-109] <https://projects.linaro.org/browse/VIRT-109> Blog Post ([LBO-34]) ==================== - started drafting a blogpost on evolution of the translator/TCG [LBO-34] <https://projects.linaro.org/browse/LBO-34> Other ===== Completed Reviews [6/6] ======================= [PATCH RFC 0/3] gitlab: build containers to use in build jobs Message-Id: <20200622153318.751107-1-berrange(a)redhat.com> [PATCH v3 00/25] risu cleanups and improvements Message-Id: <20200522023440.26261-1-richard.henderson(a)linaro.org> [PATCH v7 00/42] target/arm: Implement ARMv8.5-MemTag, system mode Message-Id: <20200603011317.473934-1-richard.henderson(a)linaro.org> - CLOSING NOTE [2020-07-01 Wed 14:57] Already merged Added: <2020-06-18 Thu> [PATCH 0/3] target/avr: Few fixes Message-Id: <20200707064646.7603-1-f4bug(a)amsat.org> [PATCH 00/21] target/xtensa: implement double precision FPU Message-Id: <20200706234737.32378-3-jcmvbkbc(a)gmail.com> - CLOSING NOTE [2020-07-07 Tue 12:31] Only looked at softfloat bits. Added: <2020-07-07 Tue> [RFC 60/65] softfloat: add fp16 and uint8/int8 interconvert functions Message-Id: <20200710104920.13550-61-frank.chang(a)sifive.com> Absences ======== - Home-schooling in mornings Current Review Queue ==================== * [PATCH v3 00/19] mailmap: Add more entries to sanitize 'git log' output Message-Id: <20200702173818.14651-1-f4bug(a)amsat.org> Added: <2020-07-02 Thu> * [PATCH v3 0/9] memory: assert and define MemoryRegionOps callbacks Message-Id: <20200630122710.1119158-1-ppandit(a)redhat.com> Added: <2020-06-30 Tue> * [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU Message-Id: <cover.1578407802.git.jan.kiszka(a)siemens.com> Added: <2020-04-09 Thu> * [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com> Added: <2020-06-13 Sat> -- Alex Bennée

5 years, 3 months

1
0
0 0

[ACTIVITY] report week ending 10 Jul

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + softfreeze this week, so a lot of handling of pull requests, reviewing various patchsets, sorting through newly reported Coverity issues, etc etc. thanks -- PMM

5 years, 3 months

1
0
0 0

[ACTIVITY] 6-10 July 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported a few regressions / minor testcase fix - enabled gcc-testresults for release branches, which will send even more emails * benchmarking: - added HAL support for the stm32 board we have in the Lab. Will start testing once the board is actually connected to a builder * misc: - infra patches/reviews == Next == * Holidays next two weeks, back on July 28th * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 3 months

1
0
0 0

[ACTIVITY] 6 - 10 July 2020

by Diana Picus

== Progress == * Uploaded binaries for llvm 10.0.1 rc3 and rc4 * More work on Morello (including docs) == Plan == * More Morello * On vacation between July 20 - 31

5 years, 3 months

1
0
0 0

[ACTIVITY] week ending 5 Jul 2020

by Richard Henderson

4 day week. [VIRT-327 # Richard's upstream QEMU work ] Bug hunting vs aa32 ldrex/strex. I had hoped it would be relatively easy to reproduce -- just run something from the .NET testsuite -- but even getting that far wasn't obvious. So I put that aside; let's see if Peter's request for an actual reproducer gets results. Bug hunting vs aa64 gcc sync-4.c as reported by clyon. I determined that it's not the fault of the null-pointer dereference, and that something goes wrong somewhere in libgcc's exception unwind prior to the c++ throw. But it doesn't fail all of the time. And worse, the problem vanishes when randomize_va_space is disabled. So I can neither get a "good" vs "bad" trace without needless differences nor produce a failure under gdb. I should try again with rr and see if that works... r~

5 years, 3 months

2
2
0 0

Re: buildbot failure in LLVM on clang-cmake-armv7-full

by David Blaikie

Linaro folks - why is this buildbot sending mail when it's already red (looks like this buildbot has been red for a while, at least 11187 seems to be red for the same reason that 11188 is red - so the people on this blame list aren't relevant)? That adds noise to the buildbot results & makes it harder for developers to find actionable email. On Mon, Jul 6, 2020 at 9:30 PM <llvm.buildmaster(a)lab.llvm.org> wrote: > > The Buildbot has detected a new failure on builder clang-cmake-armv7-full while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/11188 > > Buildbot URL: http://lab.llvm.org:8011/ > > Buildslave for this Build: linaro-tk1-08 > > Build Reason: scheduler > Build Source Stamp: [branch master] 0c6b6e28e70c06a3cb4704d2d8f90829a689e230 > Blamelist: Amara Emerson <amara(a)apple.com>,Amy Kwan <amy.kwan1(a)ibm.com>,Biplob Mishra <biplmish(a)in.ibm.com>,David Blaikie <dblaikie(a)gmail.com>,Eric Christopher <echristo(a)gmail.com>,Jordan Rupprecht <rupprecht(a)google.com>,LLVM GN Syncbot <llvmgnsyncbot(a)gmail.com>,Nico Weber <thakis(a)chromium.org>,Sanjay Patel <spatel(a)rotateright.com>,Wolfgang Pieb <wolfgang_pieb(a)playstation.sony.com>,Yuanfang Chen <yuanfang.chen(a)sony.com> > > BUILD FAILED: failed build stage 2 > > sincerely, > -The Buildbot > > >

5 years, 3 months

2
2
0 0

[ACTIVITY] 29 June-3 July 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported a few regressions - added fortran to arm-none-eabi configs - enabled gcc-testresults for most configurations, which now sends a lot of emails * GCC: - PR94743 (IRQ handler and Neon registers): patch committed. * benchmarking: - cleanup of hal lib to run benchmarks on stm32, the board we have in TCWG is different from the ones we used in ST, I'll have to update the hal settings accordingly. * misc: - switch tcwg_gnu job to use our gcc-compare-results script, to be able to ignore some tests with random results (especially under qemu) == Next == * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking

5 years, 4 months

1
0
0 0

[ACTIVITY] three weeks ending 28 Jun 2020

by Richard Henderson

[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ] Lots of work here, finally merging MTE system support. [VIRT-349 # QEMU SVE2 Support ] Posted v2, all 100 patches. [VIRT-327 # Richard's upstream QEMU work ] A fair amount of patch review. Merged the decodetree exclusive groups feature. r~

5 years, 4 months

1
0
0 0

[ACTIVITY] 22 - 26 June 2020

by Prathamesh Kulkarni

== This Week == * GCC - GNU-659 (LTO regressing calculix): Running and analysing benchmarks with different configs. * LLVM - LVM-611 (heuristic to lower calls to blx for armv6-m): Addressing upstream suggestions. - LLVM-612 (code-gen for imm8 args for Thumb1): Posted patch upstream, waiting for feedback. * Validation - Prototype script for metric based comparison == Next Week == - Continue ongoing tasks

5 years, 4 months

1
0
0 0

[ACTIVITY] report week ending 26 Jun

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + respun the QEMU side of the "fix 32-bit-guest readdir of ext4 filesystems on a 64-bit host" work to match Linus Walleij's most recent kernel patch. + code review (actually emptied my queue for the first time in forever): - patchset adding some missing devices to MPS2 boards - another round of RTH's MTE patchset (now fully reviewed and ready to go in) - SMMUv3.2 range-invalidation support patchset from RedHat - RTH's implementation of the kernel MTE ABI for QEMU linux-user + had a look at some of the lurking Coverity issues * VIRT-364 [QEMU support for ARMv8.1-M extensions] + fp16 support: started by working out risu patterns for all the affected instructions so we have a means for testing the changes. + implemented a handful of fp16 insns; plan to back-burner this for a little while as it's not going to be complete before we freeze for QEMU 5.1, so work like reviewing the MTE patchset and other for-5.1 efforts will take priority. NB: on holiday next week thanks -- PMM

5 years, 4 months

1
0
0 0

[ACTIVITY] 22-26 June 2020

by Christophe Lyon

== Progress == * GCC upstream validation: - reported a few regressions * GCC: - PR94743 (IRQ handler and Neon registers): No feedback yet. * misc: - cleanup of hal lib to run benchmarks on stm32 == Next == * PR94743 * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * FDPIC GDB

5 years, 4 months

1
0
0 0

[ACTIVITY] week ending Jun. 21 2020

by Alex Bennée

VirtIO Related Work ([VIRT-366]) ================================ - posted [PATCH v2 0/5] some tweaks to the document build process Message-Id: <20200619204959.7877-1-alex.bennee(a)linaro.org> Upstream Work ([VIRT-109]) ========================== - posted [PATCH v2] docs/devel: add some notes on tcg-icount for developers Message-Id: <20200619170930.11704-1-alex.bennee(a)linaro.org> [VIRT-109] <https://projects.linaro.org/browse/VIRT-109> Completed Reviews [7/7] ======================= [RFC v5 0/4] QEMU cpus.c refactoring Message-Id: <20200615180346.3992-1-cfontana(a)suse.de> [PATCH v1 1/2] semihosting: defer connect_chardevs a little more to use serialx Message-Id: <1592215252-26742-1-git-send-email-frederic.konrad(a)adacore.com> - CLOSING NOTE [2020-06-16 Tue 16:14] A little confused as to the purpose of patch 1/2. Added: <2020-06-15 Mon> [PATCH 0/5] linux-user: Support extended clone(CLONE_VM) Message-Id: <20200612014606.147691-1-jkz(a)google.com> - CLOSING NOTE [2020-06-16 Tue 17:08] This is super hairy stuff. Would like to know the use case for all this additional complexity. Added: <2020-06-12 Fri> [PATCH v2 00/15] tests/tcg: Add TriCore tests Message-Id: <20200604085441.103087-1-kbastian(a)mail.uni-paderborn.de> - CLOSING NOTE [2020-06-16 Tue 18:29] A few minor comments, v2 should be mergable. Added: <2020-06-04 Thu> [PATCH 0/3] Add Scripts for Finding Top 25 Executed Functions Message-Id: <20200616231204.8850-1-ahmedkhaledkaraman(a)gmail.com> [RFC] ivshmem v2: Shared memory device specification Message-Id: <f109fe5a-92eb-e5a5-bb83-ada42b3a9b61(a)siemens.com> - CLOSING NOTE [2020-06-17 Wed 16:49] Finally got round to making some comments. All in all looks pretty sane. Added: <2020-05-25 Mon> [PATCH v9 0/9] tests/vm: Add support for aarch64 VMs Message-Id: <20200601211421.1277-1-robert.foley(a)linaro.org> Absences ======== - Home-schooling in mornings Current Review Queue ==================== * [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU Message-Id: <cover.1578407802.git.jan.kiszka(a)siemens.com> Added: <2020-04-09 Thu> * [PATCH v7 00/42] target/arm: Implement ARMv8.5-MemTag, system mode Message-Id: <20200603011317.473934-1-richard.henderson(a)linaro.org> Added: <2020-06-18 Thu> * [PATCH RFC 00/22] Support of Virtual CPU Hotplug for ARMv8 Arch Message-Id: <20200613213629.21984-1-salil.mehta(a)huawei.com> Added: <2020-06-13 Sat> * [PATCH v8 0/4] vhost-user block device backend implementation Message-Id: <20200604233538.256325-1-coiby.xu(a)gmail.com> Added: <2020-06-12 Fri> -- Alex Bennée

5 years, 4 months

1
0
0 0

[ACTIVITY] report week ending Jun 19

by Peter Maydell

Progress: * VIRT-65 [QEMU upstream maintainership] + code review: - a fix for an A9 global timer device bug - imx_fec ethernet bugfixes/cleanups - SD card emulation bugfixes/cleanups (including a CVE fix) - sm501 graphics card minor fixes - implementation of qemu_init_exec_dir() for OSX - patchset adding some missing devices to MPS2 boards - RTH's v7 MemTag emulation series (this was a big one, took most of a couple of days to work through) + sent docs patch deprecating our tilegx port + discussion about what exactly target code has to do for icount support; wrote some patches to remove some 'gen_io_end()' calls that turn out to be no-longer-necessary * VIRT-364 [QEMU support for ARMv8.1-M extensions] + completed the neon decodetree conversion and sent the last batch of patches out for review; plan to start on fp16 support next NB: have recorded my maintainership work under the old VIRT-65 for now; not yet clear when/which jira issue to use in the new UM-* hierarchy. thanks -- PMM

5 years, 4 months

1
0
0 0

[ACTIVITY] 15-19 June 2020

by Christophe Lyon

* Training all week == Progress == * GCC upstream validation: - reported a few regressions - enabled sending of some validation results to gcc-testresults mailing-list * GCC: - PR94743 (IRQ handler and Neon registers): No feedback yet. * misc: - infra fixes / troubleshooting / reviews - cleanup of hal lib to run benchmarks on stm32 == Next == * PR94743 * GCC/cortex-M testing improvements & fixes * cortex-m benchmarking * FDPIC GDB

5 years, 4 months

1
0
0 0

[ACTIVITY] report week ending 12 Jun

by Peter Maydell

* VIRT-364 [QEMU support for ARMv8.1-M extensions] + Good progress with the neon decodetree conversion this week -- now feels like it's nearly done. Wrote and sent out another couple of patchsets for review. The only remaining insns to convert are the 2-reg-misc grouping. Have made a start on that; hope to get the final part of the conversion out for review next week. thanks -- PMM

5 years, 4 months

1
0
0 0

[ACTIVITY] 8-12 June 2020

by Christophe Lyon

(0.5 day off) == Progress == * GCC upstream validation: - scripts updates and cleanup for cortex-m33 with qemu-system-mode - investigated a random error with a C++ testcase under qemu-aarch64 since I upgraded to qemu-5.0. - reported a few regressions - fixed cross-build of GCC after C++11 upgrade, looked at fixing native builds (different problem), but someone had already posted the same fix during the week-end * GCC: - PR94743 (IRQ handler and Neon registers): No feedback yet. * misc: - infra fixes / troubleshooting / reviews - looking at cortex-m benchmarking harnesses. Updated docker images to include openocd and checked I could connect to the board from a docker container. - helping test Dejagnu new master branch in preparation for next stable release == Next == * training next week

5 years, 4 months

1
0
0 0

[ACTIVITY] week ending Jun. 7 2020

by Alex Bennée

VirtIO Related Work ([VIRT-366]) ================================ - virtio sync-up call 4/6/2020 [VIRT-366] <https://projects.linaro.org/browse/VIRT-366> VirtIO RPMB ([VIRT-371]) - continued working on vhost-user-rpmb daemon - solved doorbell issue with TCG and vhost-user - posted [PATCH v2] hw/virtio/vhost: re-factor vhost-section and allow DIRTY_MEMORY_CODE Message-Id: <20200604134022.10564-1-alex.bennee(a)linaro.org> [VIRT-371] <https://projects.linaro.org/browse/VIRT-371> [simplified testing branch] <http://git.linaro.org/people/alex.bennee/linux.git/shortlog/refs/heads/revi…> Upstream Work ([VIRT-109]) ========================== - posted [PATCH v1 0/9] plugins/next (bug fixes, hwprofile, lockstep) Message-Id: <20200602154624.4460-1-alex.bennee(a)linaro.org> - posted [PATCH v2] exec: flush the whole TLB if a watchpoint crosses a page boundary Message-Id: <20200603112442.22833-1-alex.bennee(a)linaro.org> - posted [PATCH v1 00/14] various fixes for next PR (testing, vhost, guest_base fixes) Message-Id: <20200605154929.26910-1-alex.bennee(a)linaro.org> [VIRT-109] <https://projects.linaro.org/browse/VIRT-109> Completed Reviews [2/2] ======================= [PATCH v8 00/12] tests/vm: Add support for aarch64 VMs Message-Id: <6f29b51c-b8d6-772c-eb24-b4c88c6c2d62(a)redhat.com> [PATCH v1 01/12] configure: add --enable-tsan flag + fiber annotations for coroutine-ucontext Message-Id: <20200529132341.755-5-robert.foley(a)linaro.org> Absences ======== - Home-schooling in mornings Current Review Queue ==================== * [PATCH 0/7] softfloat, target/i386: fprem, fprem1 fixes Message-Id: <alpine.DEB.2.21.2006051857110.13777(a)digraph.polyomino.org.uk> Added: <2020-06-06 Sat> * [PATCH v2 00/15] tests/tcg: Add TriCore tests Message-Id: <20200604085441.103087-1-kbastian(a)mail.uni-paderborn.de> Added: <2020-06-04 Thu> * [RFC v3 0/8] vDPA support in qemu Message-Id: <20200529140620.28759-1-lulu(a)redhat.com> Added: <2020-05-29 Fri> * [PATCH v3 00/11] Record/replay acceptance tests Message-Id: <159073587336.20809.5404476664125786279.stgit@pasha-ThinkPad-X280> Added: <2020-05-29 Fri> -- Alex Bennée

5 years, 4 months

1
0
0 0

[ACTIVITY] week ending 7 Jun 2020

by Richard Henderson

[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ] Posted v7 of system mode Posted v2 of user mode vs in-progress kernel abi. Some bug fixing for Stephen and Szabolcs. [VIRT-349 # QEMU SVE2 Support ] Started reviewing Stephen's sve2 risu patches. [VIRT-327 # Richard's upstream QEMU work ] A fair amount of patch review New version of decodetree exclusive groups. Some work on clang 10 werrors. r~

5 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain