CoreSight

coresight@lists.linaro.org

6 participants
2592 discussions

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

5 years, 1 month

Re: Clothing Manufacturing

by Scott Taylor

Re: Clothing Hello, Happy Monday, Hope you are well. *Who can I speak to about branding and custom apparel for your brand? * One of the largest custom clothing manufacturer, our office is in London, Sydney, HQ in Beverly Hills, California. We currently work with some top brands and companies worldwide and would love to discuss your branding and custom clothing with you. If you can direct me to the right direction, I would truly appreciate that, as we are factory direct and can save you 30% cost on your bills. *Items we manufacture: * - T-Shirts - Hoodies - Jackets - Activewear - Towels - Bags, clutches, and pouches - Hats - Promotional items - Custom Cotton Masks - Sublimated Apparel - Sports Uniform We are very creative, innovative, and offer you a full design team and direct factory. We will do everything right, and provide amazing quality at competitive prices which can be very effective for your brand development and growth. Let me know if you have a moment to discuss this. I can also get some designs done for you. *Our MOQ is 500 pcs per style,* multiple sizes. *Let me know your thoughts * Thanks Scott oasisapparel.com by The Dioz Group of Companies. Scott Taylor 8730 Wilshire Blvd, Penthouse , Beverly Hills , CA 90211 Unsubscribe ( http://mail.oasisapparels.best/wf/unsubscribe?upn=z5DQumGK2SuBD73LnAzOdSSiM… )

5 years, 1 month

[PATCH] coresight: tmc-etr: Assign boolean values to a bool variable

by xiakaixu1987＠gmail.com

From: Kaixu Xia <kaixuxia(a)tencent.com> Fix the following coccinelle warnings: ./drivers/hwtracing/coresight/coresight-tmc-etr.c:957:2-15: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Kaixu Xia <kaixuxia(a)tencent.com> --- drivers/hwtracing/coresight/coresight-tmc-etr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c index 714f9e867e5f..c86f8f2a2526 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c @@ -954,11 +954,11 @@ static void tmc_sync_etr_buf(struct tmc_drvdata *drvdata) dev_dbg(&drvdata->csdev->dev, "tmc memory error detected, truncating buffer\n"); etr_buf->len = 0; - etr_buf->full = 0; + etr_buf->full = false; return; } - etr_buf->full = status & TMC_STS_FULL; + etr_buf->full = (status & TMC_STS_FULL ? true : false); WARN_ON(!etr_buf->ops || !etr_buf->ops->sync); -- 2.20.0

5 years, 1 month

Re: Sublimated Masks/ Cotton Masks/ Clothing

by Tony FB

Re: Clothing Hello, *Who can I speak to about branding and custom apparel for your brand For:* 1. T-Shirts / Polo Shirts / Tanks 2. Jackets / Hoodies / Vests 3. Gym, Yoga and Running Apparel 4. Promotional Apparel 5. Sublimated Apparel 6. Towels, Bags, Socks and Hats *7. Cotton Masks / Sublimated Masks* We have offices in the USA , UK, Australia, India , and China. We can ship globally for you and also help you with all your designs and make pre-production samples for quality and size checks. Our MOQ is 300-1000 pcs, depending on the item. We also have the best price guarantee, our factory is tested and audited. Let me know if you have any questions Thanks in advance, Tony FB Oasis Apparel www.oasisapparel.com ( http://www.oasisapparel.com/?utm_medium=Mask&utm_campaign=website&utm_sourc… ) Tony FB Penthouse, 8730 Wilshire Blvd, Beverly Hills, California , Beverly Hills , CA 90211 Unsubscribe ( http://diozgroup.8healthusa.com/wf/unsubscribe?upn=z5DQumGK2SuBD73LnAzOdSSi… )

5 years, 1 month

[PATCH v5 0/9] perf cs-etm: Support thread stack and callchain

by Leo Yan

This patch series adds support for thread stack and callchain; this patch set depends on the instruction sample fix patch set [1]. This patch set get more complex, so before divide into small groups, I'd like to use this patch set version to include all relevant patches, hope this can give whole context for related code change. Briefly, this patch can be divided into three parts, which also can be reviewed separately for every part: Patches 01, 02 are used to fix samples for one corner case is for accessing the branch's target address and trigger an exception. Essentially, an extra branch sample is added to reflect this mediate branch between the previous branch and exception entry. Patches 03, 04, 05, 06 are coming from patch v4, which are used to support thread stack and callchain. Patches 07, 08, 09 are used to fixup for exception entry and exit. This is mainly used to fix two cases, one part is to fixup the thread stack and callchain for the case when access branch target address and trigger exception; another part is to fixup the thread stack for instruction emulation (and other single step cases). This patch set has been tested on Juno-r2 after applied on perf/core branch with latest commit 85fc95d75970 ("perf maps: Add missing unlock to maps__insert() error case"), and this patch set is also applied on top of instruction sample fix patch set [1]. Test for option '-F,+callindent': # perf script -F,+callindent main 3258 1 branches: main ffffad684d20 __libc_start_main+0xe0 (/usr/lib/aarch64-linux-gnu/libc-2.28.so) main 3258 1 branches: lib_loop_test@plt aaaae2c4d78c main+0x18 (/root/coresight_test/main) main 3258 1 branches: _dl_fixup ffffad811b4c _dl_runtime_resolve+0x40 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 1 branches: _dl_lookup_symbol_x ffffad80c078 _dl_fixup+0xb8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 1 branches: do_lookup_x ffffad80849c _dl_lookup_symbol_x+0x104 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 1 branches: check_match ffffad807bf0 do_lookup_x+0x238 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 1 branches: strcmp ffffad807888 check_match+0x70 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 1 branches: lib_loop_test@plt aaaae2c4d78c main+0x18 (/root/coresight_test/main) main 3258 1 branches: lib_loop_test@plt aaaae2c4d78c main+0x18 (/root/coresight_test/main) main 3258 1 branches: lib_loop_test@plt aaaae2c4d78c main+0x18 (/root/coresight_test/main) main 3258 1 branches: lib_loop_test@plt aaaae2c4d78c main+0x18 (/root/coresight_test/main) [...] Test for option '--itrace=g': # perf script --itrace=g16l64i100 main 3258 100 instructions: ffffad816a80 memcpy+0x70 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad809468 _dl_new_object+0xa8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad801840 dl_main+0x778 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad81384c _dl_sysdep_start+0x36c (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800884 _dl_start_final+0xac (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800b00 _dl_start+0x200 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800048 _start+0x8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 100 instructions: ffffad80952c _dl_new_object+0x16c (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad801840 dl_main+0x778 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad81384c _dl_sysdep_start+0x36c (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800884 _dl_start_final+0xac (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800b00 _dl_start+0x200 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800048 _start+0x8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 100 instructions: ffffad8018dc dl_main+0x814 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad81384c _dl_sysdep_start+0x36c (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800884 _dl_start_final+0xac (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800b00 _dl_start+0x200 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800048 _start+0x8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) main 3258 100 instructions: ffff8000100878d0 el0_sync_handler+0x168 ([kernel.kallsyms]) ffff800010082d00 el0_sync+0x140 ([kernel.kallsyms]) ffffad801910 dl_main+0x848 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad81384c _dl_sysdep_start+0x36c (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800884 _dl_start_final+0xac (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800b00 _dl_start+0x200 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) ffffad800048 _start+0x8 (/usr/lib/aarch64-linux-gnu/ld-2.28.so) [...] Changes from v4: * Addressed Mike's suggestion for performance improvement for function cs_etm__instr_addr() for quick calculation for non T32; * Removed the patch 'perf cs-etm: Synchronize instruction sample with the thread stack' (Mike); * Fixed the issue for exception is taken for branch target address accessing, for the branch sample and stack thread handling, the related patches are 01, 02, 07; * Fixed the stack thread handling for instruction emulation and single step with patches 08, 09. Changes from v3: * Split out separate patch set for instruction samples fixing. * Rebased on latest perf/core branch. Changes from v2: * Added patch 01 to fix the unsigned variable comparison to zero (Suzuki). * Refined commit logs. Changes from v1: * Added comments for task thread handling (Mathieu). * Split patch 02 into two patches, one is for support thread stack and another is for callchain support (Mathieu). * Added a new patch to support branch filter. [1] https://lkml.org/lkml/2020/2/18/1406 Leo Yan (9): perf cs-etm: Defer to assign exception sample flag perf cs-etm: Reflect branch prior to exception perf cs-etm: Refactor instruction size handling perf cs-etm: Support thread stack perf cs-etm: Support branch filter perf cs-etm: Support callchain for instruction sample perf cs-etm: Fixup exception entry for thread stack perf thread: Add helper to get top return address perf cs-etm: Fixup exception exit for thread stack .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 1 + tools/perf/util/cs-etm.c | 290 ++++++++++++++++-- tools/perf/util/thread-stack.c | 10 + tools/perf/util/thread-stack.h | 1 + 4 files changed, 268 insertions(+), 34 deletions(-) -- 2.17.1

5 years, 1 month

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

5 years, 1 month

[PATCHv2 0/4] coresight: etf/etb10/etr: Fix NULL pointer dereference crashes

by Sai Prakash Ranjan

There was a report of NULL pointer dereference in ETF enable path for perf CS mode with PID monitoring. It is almost 100% reproducible when the process to monitor is something very active such as chrome and with ETF as the sink and not ETR. Currently in a bid to find the pid, the owner is dereferenced via task_pid_nr() call in tmc_enable_etf_sink_perf() and with owner being NULL, we get a NULL pointer dereference. Looking at the ETR and other places in the kernel, ETF and the ETB are the only places trying to dereference the task(owner) in tmc_enable_etf_sink_perf() which is also called from the sched_in path as in the call trace. Owner(task) is NULL even in the case of ETR in tmc_enable_etr_sink_perf(), but since we cache the PID in alloc_buffer() callback and it is done as part of etm_setup_aux() when allocating buffer for ETR sink, we never dereference this NULL pointer and we are safe. So lets do the same thing with ETF and ETB and cache the PID to which the cs_buffer belongs in alloc_buffer() callback for ETF and ETB as done for ETR. This will also remove the unnecessary function calls (task_pid_nr()) in tmc_enable_etr_sink_perf() and etb_enable_perf(). In addition to this, add a check to validate event->owner before dereferencing it in ETR, ETB and ETF to avoid any possible NULL pointer dereference crashes in their corresponding alloc_buffer callbacks and check for kernel events as well. Easily reproducible running below: perf record -e cs_etm/@tmc_etf0/ -N -p <pid> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000548 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 <snip>... Call trace: tmc_enable_etf_sink+0xe4/0x280 coresight_enable_path+0x168/0x1fc etm_event_start+0x8c/0xf8 etm_event_add+0x38/0x54 event_sched_in+0x194/0x2ac group_sched_in+0x54/0x12c flexible_sched_in+0xd8/0x120 visit_groups_merge+0x100/0x16c ctx_flexible_sched_in+0x50/0x74 ctx_sched_in+0xa4/0xa8 perf_event_sched_in+0x60/0x6c perf_event_context_sched_in+0x98/0xe0 __perf_event_task_sched_in+0x5c/0xd8 finish_task_switch+0x184/0x1cc schedule_tail+0x20/0xec ret_from_fork+0x4/0x18 Sai Prakash Ranjan (4): perf/core: Export is_kernel_event() coresight: tmc-etf: Fix NULL ptr dereference in tmc_enable_etf_sink_perf() coresight: etb10: Fix possible NULL ptr dereference in etb_enable_perf() coresight: tmc-etr: Fix possible NULL ptr dereference in get_perf_etr_buf_cpu_wide() drivers/hwtracing/coresight/coresight-etb10.c | 8 +++++++- drivers/hwtracing/coresight/coresight-priv.h | 2 ++ drivers/hwtracing/coresight/coresight-tmc-etf.c | 8 +++++++- drivers/hwtracing/coresight/coresight-tmc-etr.c | 6 +++++- include/linux/perf_event.h | 2 ++ kernel/events/core.c | 3 ++- 6 files changed, 25 insertions(+), 4 deletions(-) base-commit: f4cb5e9daedf56671badc93ac7f364043aa33886 -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

5 years, 1 month

GDB: etm traces decoding and breakpoints for arm targets

by Zied Guermazi

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

5 years, 1 month

[PATCH] coresight: Remove unnecessary THIS_MODULE of funnel and replicator driver

by Qi Liu

As THIS_MODULE has been set in platform_driver_register(), so remove it from static funnel driver and static replicator driver to avoid set it twice. Signed-off-by: Qi Liu <liuqi115(a)huawei.com> --- drivers/hwtracing/coresight/coresight-funnel.c | 2 +- drivers/hwtracing/coresight/coresight-replicator.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c index af40814..39be46b 100644 --- a/drivers/hwtracing/coresight/coresight-funnel.c +++ b/drivers/hwtracing/coresight/coresight-funnel.c @@ -356,7 +356,7 @@ static struct platform_driver static_funnel_driver = { .remove = static_funnel_remove, .driver = { .name = "coresight-static-funnel", - .owner = THIS_MODULE, + /* THIS_MODULE is taken care of by platform_driver_register() */ .of_match_table = static_funnel_match, .acpi_match_table = ACPI_PTR(static_funnel_ids), .pm = &funnel_dev_pm_ops, diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c index 62afdde..6772f23 100644 --- a/drivers/hwtracing/coresight/coresight-replicator.c +++ b/drivers/hwtracing/coresight/coresight-replicator.c @@ -374,7 +374,7 @@ static struct platform_driver static_replicator_driver = { .remove = static_replicator_remove, .driver = { .name = "coresight-static-replicator", - .owner = THIS_MODULE, + /* THIS_MODULE is taken care of by platform_driver_register() */ .of_match_table = of_match_ptr(static_replicator_match), .acpi_match_table = ACPI_PTR(static_replicator_acpi_ids), .pm = &replicator_dev_pm_ops, -- 2.8.1

5 years, 1 month

Re: [PATCH 30/33] docs: ABI: cleanup several ABI documents

by Bjorn Andersson

On Wed 28 Oct 09:23 CDT 2020, Mauro Carvalho Chehab wrote: [..] > .../ABI/testing/sysfs-class-remoteproc | 14 +- for this: Acked-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Thanks, Bjorn

5 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight