CoreSight

coresight@lists.linaro.org

7 participants
2448 discussions

[PATCH] coresight: Fix all W=1 build warnings

by James Clark

The kernel test robot looks for new warnings in a W=1 build, so fix all the existing warnings to make it easier to spot new ones when building locally. The fixes are for undocumented function arguments and an incorrect doc style. Signed-off-by: James Clark <james.clark(a)arm.com> --- drivers/hwtracing/coresight/coresight-cti-core.c | 2 +- drivers/hwtracing/coresight/coresight-etm4x-cfg.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-cti-core.c b/drivers/hwtracing/coresight/coresight-cti-core.c index 7023ff70cc28..3999d0a2cb60 100644 --- a/drivers/hwtracing/coresight/coresight-cti-core.c +++ b/drivers/hwtracing/coresight/coresight-cti-core.c @@ -22,7 +22,7 @@ #include "coresight-priv.h" #include "coresight-cti.h" -/** +/* * CTI devices can be associated with a PE, or be connected to CoreSight * hardware. We have a list of all CTIs irrespective of CPU bound or * otherwise. diff --git a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c index d2ea903231b2..c302072b293a 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-cfg.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-cfg.c @@ -40,7 +40,7 @@ * Invalid offsets will result in fail code return and feature load failure. * * @drvdata: driver data to map into. - * @reg: register to map. + * @reg_csdev: register to map. * @offset: device offset for the register */ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata, @@ -132,7 +132,7 @@ static int etm4_cfg_map_reg_offset(struct etmv4_drvdata *drvdata, * etm4_cfg_load_feature - load a feature into a device instance. * * @csdev: An ETMv4 CoreSight device. - * @feat: The feature to be loaded. + * @feat_csdev: The feature to be loaded. * * The function will load a feature instance into the device, checking that * the register definitions are valid for the device. -- 2.34.1

2 years, 1 month

[PATCH V6 0/6] coresight: etm4x: Migrate ACPI AMBA devices to platform driver

by Anshuman Khandual

CoreSight ETM4x devices could be accessed either via MMIO (handled via amba_driver) or CPU system instructions (handled via platform driver). But this has the following issues : - Each new CPU comes up with its own PID and thus we need to keep on adding the "known" PIDs to get it working with AMBA driver. While the ETM4 architecture (and CoreSight architecture) defines way to identify a device as ETM4. Thus older kernels won't be able to "discover" a newer CPU, unless we add the PIDs. - With ACPI, the ETM4x devices have the same HID to identify the device irrespective of the mode of access. This creates a problem where two different drivers (both AMBA based driver and platform driver) would hook into the "HID" and could conflict. e.g., if AMBA driver gets hold of a non-MMIO device, the probe fails. If we have single driver hooked into the given "HID", we could handle them seamlessly, irrespective of the mode of access. - CoreSight is heavily dependent on the runtime power management. With ACPI, amba_driver doesn't get us anywhere with handling the power and thus one need to always turn the power ON to use them. Moving to platform driver gives us the power management for free. Due to all of the above, we are moving ACPI MMIO based etm4x devices to be supported via tha platform driver. The series makes the existing platform driver generic to handle both type of the access modes. Although existing AMBA driver would still continue to support DT based etm4x MMIO devices. Although some problems still remain, such as manually adding PIDs for all new AMBA DT based devices. The series applies on 6.5-rc1. Changes in V6: - Rebased on 6.5-rc1 Changes in V5: https://lore.kernel.org/all/20230529062511.52016-1-anshuman.khandual@arm.co… - Updated the comment for apb clock in drvdata structure - Updated conditional check in etm4_runtime_suspend/resume() - Asserted that the APB clock is present and also enabled Changes in V4: https://lore.kernel.org/all/20230523044553.1525048-1-anshuman.khandual@arm.… - Changed in-code comment in etm4_check_arch_features() - Re-ordered pm_runtime_disable() in etm4_remove_platform_dev() - Renamed back etm4_match as etm4_sysreg_match - Moved back [PATCH 6/6] as [PATCH 5/6] Changes in V3: https://lore.kernel.org/all/20230519052149.1367814-1-anshuman.khandual@arm.… - Returned from etm4_check_arch_features() for non iomem devices - Renamed ETM_DEVTYPE_ETMv4x_ARCH as CS_DEVTYPE_PE_TRACE - Renamed is_etm4x_devtype() as is_devtype_cpu_trace() - Added a patch to ignore the absence of graph connections Changes in V2: https://lore.kernel.org/all/20230327050537.30861-1-anshuman.khandual@arm.co… - Enables ACPI etm4x device support in the existing platform driver - Dropped last two patches from the series - Dropped redundant 'devarch' checking from is_etm4x_device() - Renamed updated is_etm4x_device() as is_etm4x_devtype() - Fixed arguments in fallback stub for etm4_check_arch_features() - Tagged etm4_dev_pm_ops with etm4_platform_driver - Updated the comment for coresight_get_enable_apb_pclk() helper - Updated the comment for new 'pclk' element in struct etm4_drvdata - Dropped the clock when devm_ioremap_resource() fails - Convert IS_ERR() into a direct pointer check in etm4_remove_platform_dev() - Dropped "arm,coresight-etm4x" compatible property from etm4_match[] Changes in V1: https://lore.kernel.org/all/20230317030501.1811905-1-anshuman.khandual@arm.… Cc: Ganapatrao Kulkarni <gankulkarni(a)os.amperecomputing.com> Cc: Steve Clevenger <scclevenger(a)os.amperecomputing.com> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Frank Rowand <frowand.list(a)gmail.com> Cc: Russell King (Oracle) <linux(a)armlinux.org.uk> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael(a)kernel.org> Cc: Len Brown <lenb(a)kernel.org> Cc: Sudeep Holla <sudeep.holla(a)arm.com> Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: devicetree(a)vger.kernel.org Cc: linux-acpi(a)vger.kernel.org Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (4): coresight: etm4x: Allocate and device assign 'struct etmv4_drvdata' earlier coresight: etm4x: Drop iomem 'base' argument from etm4_probe() coresight: etm4x: Drop pid argument from etm4_probe() coresight: etm4x: Change etm4_platform_driver driver for MMIO devices Suzuki K Poulose (2): coresight: platform: acpi: Ignore the absence of graph coresight: etm4x: Add ACPI support in platform driver drivers/acpi/acpi_amba.c | 1 - .../coresight/coresight-etm4x-core.c | 118 ++++++++++++++---- drivers/hwtracing/coresight/coresight-etm4x.h | 4 + .../hwtracing/coresight/coresight-platform.c | 6 +- include/linux/coresight.h | 59 +++++++++ 5 files changed, 164 insertions(+), 24 deletions(-) -- 2.25.1

2 years, 1 month

Some questions about using coresight with AutoFDO to optimize the Linux kernel.

by zack.tsai＠mediatek.com

Hi,all [1] Despite not yielding any benefits in the past, it has been shown that utilizing ARM ETM+AutoFDO can optimize the Linux kernel. I am interested in determining if conducting a trial run on my platform would be beneficial. [1] https://lpc.events/event/7/contributions/798/ [2][3] Show an simple examples optimize a program using simpleperf and perf in perf method I would like to build a version of 'perf' with CORESIGHT=1 that supports ETM and can run on my platform(aarch64). OpenCSD/decoder/tests/auto-fdo/autofdo.md at master · Linaro/OpenCSD · GitHub cd linux && PYTHON=python3 && make install ARCH=arm64 CORESIGHT=1 CROSS_COMPILE=aarch64-linux-gnu- LDFLAGS=-static NO_LIBPERF_BUILD=1 NO_LIBELF=1 NO_JVMTI=1 NO_LIBPYTHON=1 NO_LIBTRACEEVENT=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 EXTRA_CFLAGS=-Wno-error -C tools/perf/ Makefile.config:525: *** Error: No libopencsd library found or the version is not up-to-date. Please install recent libopencsd to build with CORESIGHT=1. Stop. make[1]: *** [Makefile.perf:242: sub-make] Error 2 make: *** [Makefile:113: install] Error 2 make: Leaving directory '/linux/linux/tools/perf' I have already installed libopencsd through apt-get, but I am still unable to locate my library. /usr/include/opencsd How can I fix this problem? Where should I move /usr/include/opencsd to? Thanks Zack

2 years, 1 month

Re: [PATCH v2] hwtracing: coresight: Explicitly include correct DT includes

by Suzuki K Poulose

On 18/07/2023 15:31, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring <robh(a)kernel.org> > --- > v2: > - Fix double include of of.h > --- > drivers/hwtracing/coresight/coresight-core.c | 2 +- > drivers/hwtracing/coresight/coresight-platform.c | 2 -- > 2 files changed, 1 insertion(+), 3 deletions(-) Rob, Thanks for the updated version, I will queue this. Suzuki

2 years, 1 month

Re: [PATCH] hwtracing: coresight: Explicitly include correct DT includes

by Suzuki K Poulose

Hi Rob Thanks for the cleanup. Please find my comments below. On 14/07/2023 18:46, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring <robh(a)kernel.org> > --- > drivers/hwtracing/coresight/coresight-core.c | 2 +- > drivers/hwtracing/coresight/coresight-platform.c | 3 +-- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c > index 118fcf27854d..9fabe00a40d6 100644 > --- a/drivers/hwtracing/coresight/coresight-core.c > +++ b/drivers/hwtracing/coresight/coresight-core.c > @@ -17,7 +17,7 @@ > #include <linux/mutex.h> > #include <linux/clk.h> > #include <linux/coresight.h> > -#include <linux/of_platform.h> > +#include <linux/property.h> > #include <linux/delay.h> > #include <linux/pm_runtime.h> This looks correct to me. > > diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c > index 3e2e135cb8f6..d94b0e77bcfc 100644 > --- a/drivers/hwtracing/coresight/coresight-platform.c > +++ b/drivers/hwtracing/coresight/coresight-platform.c > @@ -9,9 +9,8 @@ > #include <linux/slab.h> > #include <linux/clk.h> > #include <linux/of.h> > -#include <linux/of_address.h> > +#include <linux/of.h> We already include of.h two lines above, so we could skip this. > #include <linux/of_graph.h> > -#include <linux/of_platform.h> > #include <linux/platform_device.h> > #include <linux/amba/bus.h> > #include <linux/coresight.h> Suzuki

2 years, 1 month

Re: [PATCH v6 09/13] Add nodes for dsb edge control

by Tao Zhang

On 6/20/2023 3:37 PM, Greg Kroah-Hartman wrote: > On Tue, Jun 20, 2023 at 03:32:37PM +0800, Tao Zhang wrote: >> Add the nodes to set value for DSB edge control and DSB edge >> control mask. Each DSB subunit TPDM has maximum of n(n<16) EDCR >> resgisters to configure edge control. DSB edge detection control >> 00: Rising edge detection >> 01: Falling edge detection >> 10: Rising and falling edge detection (toggle detection) >> And each DSB subunit TPDM has maximum of m(m<8) ECDMR registers to >> configure mask. Eight 32 bit registers providing DSB interface >> edge detection mask control. >> >> Signed-off-by: Tao Zhang <quic_taozha(a)quicinc.com> >> --- >> .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 32 +++++ >> drivers/hwtracing/coresight/coresight-tpdm.c | 143 ++++++++++++++++++++- >> drivers/hwtracing/coresight/coresight-tpdm.h | 22 ++++ >> 3 files changed, 196 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >> index 2a82cd0..34189e4a 100644 >> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >> @@ -60,3 +60,35 @@ Description: >> Bit[3] : Set to 0 for low performance mode. >> Set to 1 for high performance mode. >> Bit[4:8] : Select byte lane for high performance mode. >> + >> +What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge_ctrl >> +Date: March 2023 >> +KernelVersion 6.5 >> +Contact: Jinlong Mao (QUIC) <quic_jinlmao(a)quicinc.com>, Tao Zhang (QUIC) <quic_taozha(a)quicinc.com> >> +Description: >> + Read/Write a set of the edge control registers of the DSB >> + in TPDM. >> + >> + Expected format is the following: >> + <integer1> <integer2> <integer3> > sysfs is "one value", not 3. Please never have to parse a sysfs file. Do you mean sysfs file can only accept "one value"? I see that more than one value are written to the sysfs file "trigout_attach". > >> +static ssize_t dsb_edge_ctrl_show(struct device *dev, >> + struct device_attribute *attr, >> + char *buf) >> +{ >> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent); >> + ssize_t size = 0; >> + unsigned long bytes; >> + int i; >> + >> + spin_lock(&drvdata->spinlock); >> + for (i = 0; i < TPDM_DSB_MAX_EDCR; i++) { >> + bytes = sysfs_emit_at(buf, size, >> + "Index:0x%x Val:0x%x\n", i, > Again, no, one value, no "string" needed to parse anything. I also see other sysfs files can be read more than one value in other drivers. Is this "one value" limitation the usage rule of Linux sysfs system? Or am I misunderstanding what you mean? Best, Tao > > greg k-h

2 years, 1 month

Re: Perf + Opencsd (aarch64) Off Target Trace Decoding shows "could not read first record/send request"

by James Clark

On 14/07/2023 06:57, Pandey, Radhey Shyam wrote: >> -----Original Message----- >> From: James Clark <james.clark(a)arm.com> >> Sent: Tuesday, July 11, 2023 10:04 PM >> To: Pandey, Radhey Shyam <radhey.shyam.pandey(a)amd.com> >> Cc: coresight(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org; Sarangi, >> Anirudha <anirudha.sarangi(a)amd.com>; mathieu.poirier(a)linaro.org; >> mike.leach(a)linaro.org; leo.yan(a)linaro.org; >> alexander.shishkin(a)linux.intel.com; Suzuki K Poulose >> <suzuki.poulose(a)arm.com> >> Subject: Re: Perf + Opencsd (aarch64) Off Target Trace Decoding shows >> "could not read first record/send request" >> >> >> >> On 11/07/2023 11:40, Suzuki K Poulose wrote: >>> On 11/07/2023 10:26, Pandey, Radhey Shyam wrote: >>>> Hi all, >>>> >>>> I am trying off Target Trace Decoding using arm-cs-trace-disasm.py >>>> but it doesn’t show >>>> >>>> proper disassembly. There is unexpected warning "could not read first >>>> record". >>> >>> >>>> >>>> Any pointers on what the issue could be? >>>> >>>> Meanwhile I am trying to do trace decoding on aarch64 target and see >>>> if that helps. >>>> >>>> I have taken simple example mentioned in [1]. >>>> >>>> [1]: >>>> http://events17.linuxfoundation.org/sites/events/files/slides/ELC-E16 >>>> .pdf >>>> <http://events17.linuxfoundation.org/sites/events/files/slides/ELC-E1 >>>> 6.pdf> >>>> >>>> #include int coresight_test1(int val); >>>> >>>> int main(void) { >>>> >>>> int val; val = coresight_test1(10); >>>> >>>> printf("val: %d\n", val); >>>> >>>> return 0; >>>> >>>> } >>>> >>>> perf record -e cs_etm/@tmc_etf0/u --filter >>>> 'filter0x5a8/0x5e4(a)/home/root/libcstest.so.1.0' --per-thread ./main >>>> >>>> tar czf cs_example.tgz perf.data ~/.debug >>>> >>>> Off Target Trace Decoding: “perf report” >>>> >>>> tar xf cs_example.tgz >>>> >>>> $ rm -rf ~/.debug // remove previous trace data >>>> >>>> $ cp -dpR .debug ~/ // copy the current trace data >>>> >>>> $ perf report --stdio >>>> >>>> linux-xlnx/tools/perf/perf --exec-path= <snip>/linux-xlnx/tools/perf >>>> script tools/perf/scripts/python/arm-cs-trace-disasm.py -- -d >>>> ${XTOOL_PATH}/aarch64-linux-gnu-objdump -v >>>> >>> >>> I believe the perf script doesn't work with coresight trace decoding >>> as we need a two pass approach for decoding the stream for figuring >>> out the parameters for the queues. James Clark can give you the exact >> reason. >>> >>> Suzuki >> >> No that script is still working, I just tried it on and off target and it's all fine. >> >> I didn't use --exec-path=, I'm not sure why that's in that linked pdf, but it >> didn't cause the same issue that you see if I added it. >> >> The "could not read first record" errors actually come from the addr2line >> part of Perf rather than this script. Do you have perf report/annotate >> working without the script? > > I tried perf capture and report on aarch64 target platform (To avoid any possible > cross-platform issue) With that perf report seems working but perf annotate is > not working. Any suggestions on what could be the issue? > Which features do you have compiled into Perf? If you don't have libelf and some others then annotate won't work: $ ldd ./perf linux-vdso.so.1 libunwind-x86_64.so.8 => /lib/x86_64-linux-gnu/libunwind-x86_64.so.8 libunwind.so.8 => /lib/x86_64-linux-gnu/libunwind.so.8 liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 libopencsd_c_api.so.1 => /lib/x86_64-linux-gnu/libopencsd_c_api.so.1 libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 libpython3.10.so.1.0 => /lib/x86_64-linux-gnu/libpython3.10.so.1.0 libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 libtraceevent.so.1 => /lib/x86_64-linux-gnu/libtraceevent.so.1 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 libopencsd.so.1 => /lib/x86_64-linux-gnu/libopencsd.so.1 libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 > Copied perf report , annotate and script o/p logs below. > > Cross-compilation steps: > aarch64-linux-gnu-gcc -shared -g libcstest.c -o libcstest.so.1.0 > aarch64-linux-gnu-gcc -g main.c -L. -l:libcstest.so.1.0 -o main > Copied it to host. > > On Target: > > perf record -e cs_etm/@tmc_etf0/u --filter 'filter 0x5a8/0x5e4(a)/home/root/libcstest.so.1.0' --per-thread ./main > val: 20 > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.002 MB perf.data ] > > xilinx-vck190-20231:~# perf report -D 2>&1 | tee > Warning: > Please install libunwind or libdw development packages during the perf build. > # To display the perf.data header info, please use --header/--header-only options. > # > > 0x198(a)perf.data [0x38]: event: 79 > . > . ... raw event: size 56 bytes > . 0000: 4f 00 00 00 00 00 38 00 15 00 00 00 00 00 00 00 O.....8......... > . 0010: 00 00 40 01 00 00 00 00 46 ab c4 36 cd ff ff ff ..@.....F..6.... > . 0020: 02 20 33 14 05 00 00 00 ff ff ff ff ff ff ff 01 . 3............. > . 0030: 01 01 00 00 00 00 00 00 ........ > > 0x198 [0x38]: PERF_RECORD_TIME_CONV > ... Time Shift 21 > ... Time Muliplier 20971520 > ... Time Zero 18446743855585078086 > ... Time Cycles 21813731330 > ... Time Mask 0x1ffffffffffffff > ... Cap Time Zero 1 > ... Cap Time Short 1 > : unhandled! > > 0x1d0(a)perf.data [0x50]: event: 69 > . > . ... raw event: size 80 bytes > . 0000: 45 00 00 00 00 00 50 00 02 00 00 00 00 00 00 00 E.....P......... > . 0010: 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0020: ff ff ff ff ff ff ff ff 46 03 00 00 00 00 00 00 ........F....... > . 0030: 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: ff ff ff ff ff ff ff ff 46 03 00 00 00 00 00 00 ........F....... > > 0x1d0 [0x50]: PERF_RECORD_ID_INDEX nr: 2 > ... id: 26 idx: 0 cpu: -1 tid: 838 > ... id: 27 idx: 0 cpu: -1 tid: 838 > > 0x220(a)perf.data [0xc8]: event: 70 > . > . ... raw event: size 200 bytes > . 0000: 46 00 00 00 00 00 c8 00 03 00 00 00 00 00 00 00 F............... > . 0010: 01 00 00 00 00 00 00 00 02 00 00 00 08 00 00 00 ................ > . 0020: 00 00 00 00 00 00 00 00 40 40 40 40 40 40 40 40 ........@@@@@@@@ > . 0030: 00 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 ................ > . 0040: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 ................ > . 0050: a1 0e 00 28 00 00 00 00 01 f4 00 41 00 00 00 00 ...(.......A.... > . 0060: 88 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0070: cc 00 00 00 00 00 00 00 40 40 40 40 40 40 40 40 ........@@@@@@@@ > . 0080: 01 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 ................ > . 0090: 00 00 00 00 00 00 00 00 12 00 00 00 00 00 00 00 ................ > . 00a0: a1 0e 00 28 00 00 00 00 01 f4 00 41 00 00 00 00 ...(.......A.... > . 00b0: 88 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 00c0: cc 00 00 00 00 00 00 00 ........ > > 0x220 [0xc8]: PERF_RECORD_AUXTRACE_INFO type: 3 > Header version 1 > PMU type/num cpus 800000002 > Snapshot 0 > Magic number 4040404040404040 > CPU 0 > NR_TRC_PARAMS 7 > TRCCONFIGR 0 > TRCTRACEIDR 10 > TRCIDR0 28000ea1 > TRCIDR1 4100f401 > TRCIDR2 488 > TRCIDR8 0 > TRCAUTHSTATUS cc > Magic number 4040404040404040 > CPU 1 > NR_TRC_PARAMS 7 > TRCCONFIGR 0 > TRCTRACEIDR 12 > TRCIDR0 28000ea1 > TRCIDR1 4100f401 > TRCIDR2 488 > TRCIDR8 0 > TRCAUTHSTATUS cc > > 0@(null) [0x90]: event: 64 > . > . ... raw event: size 144 bytes > . 0000: 40 00 00 00 00 00 90 00 00 00 00 00 80 00 00 00 @............... > . 0010: 04 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ > . 0020: 0b 01 01 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ > . 0030: 60 00 14 00 00 00 00 00 00 00 00 00 00 00 00 00 `............... > . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0080: 00 00 00 00 00 00 00 00 1a ca 9a 3b 00 00 00 00 ...........;.... > > 0 [0x90]: PERF_RECORD_ATTR > 0@(null) [0x90]: event: 64 > . > . ... raw event: size 144 bytes > . 0000: 40 00 00 00 00 00 90 00 00 00 00 00 80 00 00 00 @............... > . 0010: 01 00 00 00 00 00 00 00 a0 86 01 00 00 00 00 00 ................ > . 0020: 03 01 01 00 00 00 00 00 14 00 00 00 00 00 00 00 ................ > . 0030: 60 00 14 00 00 00 00 00 00 00 00 00 00 00 00 00 `............... > . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0080: 00 00 00 00 00 00 00 00 1b ca 9a 3b 00 00 00 00 ...........;.... > > 0 [0x90]: PERF_RECORD_ATTR > 0x2e8(a)perf.data [0x28]: event: 73 > . > . ... raw event: size 40 bytes > . 0000: 49 00 00 00 00 00 28 00 01 00 00 00 00 00 00 00 I.....(......... > . 0010: 46 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F............... > . 0020: 00 00 00 00 00 00 00 00 ........ > > 0x2e8 [0x28]: PERF_RECORD_THREAD_MAP nr: 1 thread: 838 > : unhandled! > > 0x310(a)perf.data [0x10]: event: 74 > . > . ... raw event: size 16 bytes > . 0000: 4a 00 00 00 00 00 10 00 00 00 01 00 ff ff 00 00 J............... > > 0x310 [0x10]: PERF_RECORD_CPU_MAP: -1 > : unhandled! > > 0x320(a)perf.data [0x30]: event: 3 > . > . ... raw event: size 48 bytes > . 0000: 03 00 00 00 00 00 30 00 46 03 00 00 46 03 00 00 ......0.F...F... > . 0010: 70 65 72 66 2d 65 78 65 63 00 00 00 00 00 00 00 perf-exec....... > . 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 0x320 [0x30]: PERF_RECORD_COMM: perf-exec:838/838 > > 0x350(a)perf.data [0x8]: event: 82 > . > . ... raw event: size 8 bytes > . 0000: 52 00 00 00 00 00 08 00 R....... > > 0x350 [0x8]: PERF_RECORD_FINISHED_INIT: unhandled! > > 0x358(a)perf.data [0x20]: event: 12 > . > . ... raw event: size 32 bytes > . 0000: 0c 00 00 00 00 00 20 00 46 03 00 00 46 03 00 00 ...... .F...F... > . 0010: 46 03 00 00 46 03 00 00 1a 00 00 00 00 00 00 00 F...F........... > > 0x358 [0x20]: PERF_RECORD_ITRACE_START pid: 838 tid: 838 > > 0x378(a)perf.data [0x30]: event: 11 > . > . ... raw event: size 48 bytes > . 0000: 0b 00 00 00 00 00 30 00 00 00 00 00 00 00 00 00 ......0......... > . 0010: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... > . 0020: 46 03 00 00 46 03 00 00 1a 00 00 00 00 00 00 00 F...F........... > > 0x378 [0x30]: PERF_RECORD_AUX offset: 0 size: 0x20 flags: 0 [] > > 0x3a8(a)perf.data [0x28]: event: 3 > . > . ... raw event: size 40 bytes > . 0000: 03 00 00 00 00 20 28 00 46 03 00 00 46 03 00 00 ..... (.F...F... > . 0010: 6d 61 69 6e 00 00 00 00 46 03 00 00 46 03 00 00 main....F...F... > . 0020: 1b 00 00 00 00 00 00 00 ........ > > 0x3a8 [0x28]: PERF_RECORD_COMM exec: main:838/838 > > 0x3d0(a)perf.data [0x68]: event: 10 > . > . ... raw event: size 104 bytes > . 0000: 0a 00 00 00 02 00 68 00 46 03 00 00 46 03 00 00 ......h.F...F... > . 0010: 00 00 f9 ba aa aa 00 00 00 10 02 00 00 00 00 00 ................ > . 0020: 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ................ > . 0030: a6 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .C.............. > . 0040: 05 00 00 00 02 00 00 00 2f 68 6f 6d 65 2f 72 6f ......../home/ro > . 0050: 6f 74 2f 6d 61 69 6e 00 46 03 00 00 46 03 00 00 ot/main.F...F... > . 0060: 1b 00 00 00 00 00 00 00 ........ > > 0x3d0 [0x68]: PERF_RECORD_MMAP2 838/838: [0xaaaabaf90000(0x21000) @ 0 00:02 17318 0]: r-xp /home/root/main > > 0x438(a)perf.data [0x78]: event: 10 > . > . ... raw event: size 120 bytes > . 0000: 0a 00 00 00 02 00 78 00 46 03 00 00 46 03 00 00 ......x.F...F... > . 0010: 00 c0 e3 ae ff ff 00 00 00 20 04 00 00 00 00 00 ......... ...... > . 0020: 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ................ > . 0030: f1 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: 05 00 00 00 02 00 00 00 2f 6c 69 62 2f 6c 64 2d ......../lib/ld- > . 0050: 6c 69 6e 75 78 2d 61 61 72 63 68 36 34 2e 73 6f linux-aarch64.so > . 0060: 2e 31 00 00 00 00 00 00 46 03 00 00 46 03 00 00 .1......F...F... > . 0070: 1b 00 00 00 00 00 00 00 ........ > > 0x438 [0x78]: PERF_RECORD_MMAP2 838/838: [0xffffaee3c000(0x42000) @ 0 00:02 1777 0]: r-xp /lib/ld-linux-aarch64.so.1 > > 0x4b0(a)perf.data [0x60]: event: 10 > . > . ... raw event: size 96 bytes > . 0000: 0a 00 00 00 02 00 60 00 46 03 00 00 46 03 00 00 ......`.F...F... > . 0010: 00 90 e7 ae ff ff 00 00 00 10 00 00 00 00 00 00 ................ > . 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: 05 00 00 00 02 00 00 00 5b 76 64 73 6f 5d 00 00 ........[vdso].. > . 0050: 46 03 00 00 46 03 00 00 1b 00 00 00 00 00 00 00 F...F........... > > 0x4b0 [0x60]: PERF_RECORD_MMAP2 838/838: [0xffffaee79000(0x1000) @ 0 00:00 0 0]: r-xp [vdso] > > 0x510(a)perf.data [0x30]: event: 11 > . > . ... raw event: size 48 bytes > . 0000: 0b 00 00 00 00 00 30 00 20 00 00 00 00 00 00 00 ......0. ....... > . 0010: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... > . 0020: 46 03 00 00 46 03 00 00 1a 00 00 00 00 00 00 00 F...F........... > > 0x510 [0x30]: PERF_RECORD_AUX offset: 0x20 size: 0x20 flags: 0 [] > > 0x540(a)perf.data [0x78]: event: 10 > . > . ... raw event: size 120 bytes > . 0000: 0a 00 00 00 02 00 78 00 46 03 00 00 46 03 00 00 ......x.F...F... > . 0010: 00 00 e1 ae ff ff 00 00 00 10 02 00 00 00 00 00 ................ > . 0020: 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ................ > . 0030: a8 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .C.............. > . 0040: 05 00 00 00 02 00 00 00 2f 68 6f 6d 65 2f 72 6f ......../home/ro > . 0050: 6f 74 2f 6c 69 62 63 73 74 65 73 74 2e 73 6f 2e ot/libcstest.so. > . 0060: 31 2e 30 00 00 00 00 00 46 03 00 00 46 03 00 00 1.0.....F...F... > . 0070: 1b 00 00 00 00 00 00 00 ........ > > 0x540 [0x78]: PERF_RECORD_MMAP2 838/838: [0xffffaee10000(0x21000) @ 0 00:02 17320 0]: r-xp /home/root/libcstest.so.1.0 > > 0x5b8(a)perf.data [0x68]: event: 10 > . > . ... raw event: size 104 bytes > . 0000: 0a 00 00 00 02 00 68 00 46 03 00 00 46 03 00 00 ......h.F...F... > . 0010: 00 00 c6 ae ff ff 00 00 00 f0 1a 00 00 00 00 00 ................ > . 0020: 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ................ > . 0030: ff 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > . 0040: 05 00 00 00 02 00 00 00 2f 6c 69 62 2f 6c 69 62 ......../lib/lib > . 0050: 63 2e 73 6f 2e 36 00 00 46 03 00 00 46 03 00 00 c.so.6..F...F... > . 0060: 1b 00 00 00 00 00 00 00 ........ > > 0x5b8 [0x68]: PERF_RECORD_MMAP2 838/838: [0xffffaec60000(0x1af000) @ 0 00:02 1791 0]: r-xp /lib/libc.so.6 > > 0x620(a)perf.data [0x30]: event: 11 > . > . ... raw event: size 48 bytes > . 0000: 0b 00 00 00 00 00 30 00 40 00 00 00 00 00 00 00 ......0.@....... > . 0010: 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 P............... > . 0020: 46 03 00 00 46 03 00 00 1a 00 00 00 00 00 00 00 F...F........... > > 0x620 [0x30]: PERF_RECORD_AUX offset: 0x40 size: 0x50 flags: 0 [] > > 0x650(a)perf.data [0x30]: event: 4 > . > . ... raw event: size 48 bytes > . 0000: 04 00 00 00 00 00 30 00 46 03 00 00 45 03 00 00 ......0.F...E... > . 0010: 46 03 00 00 45 03 00 00 66 a0 a1 b2 5b 03 00 00 F...E...f...[... > . 0020: 46 03 00 00 46 03 00 00 1b 00 00 00 00 00 00 00 F...F........... > > 0x650 [0x30]: PERF_RECORD_EXIT(838:838):(837:837) > > 0x680(a)perf.data [0x30]: event: 71 > . > . ... raw event: size 48 bytes > . 0000: 47 00 00 00 00 00 30 00 90 00 00 00 00 00 00 00 G.....0......... > . 0010: 00 00 00 00 00 00 00 00 c5 4c 5e 73 59 08 d6 7b .........L^sY..{ > . 0020: 00 00 00 00 46 03 00 00 ff ff ff ff 00 00 00 00 ....F........... > > 0x680 [0x30]: PERF_RECORD_AUXTRACE size: 0x90 offset: 0 ref: 0x7bd60859735e4cc5 idx: 0 tid: 838 cpu: -1 > > . ... CoreSight ETMV4I Trace data: size 0x20 bytes > Idx:0; ID:12; I_ASYNC : Alignment Synchronisation. > Idx:12; ID:12; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > > . ... CoreSight ETMV4I Trace data: size 0x20 bytes > Idx:32; ID:12; I_ASYNC : Alignment Synchronisation. > Idx:44; ID:12; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > > . ... CoreSight ETMV4I Trace data: size 0x50 bytes > Idx:64; ID:12; I_ASYNC : Alignment Synchronisation. > Idx:76; ID:12; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > Idx:81; ID:12; I_TRACE_ON : Trace On. > Idx:82; ID:12; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x0000FFFFAEE105A8; Ctxt: AArch64,EL0, NS; > Idx:92; ID:12; I_ATOM_F6 : Atom format 6.; EEEEEEN > Idx:93; ID:12; I_ATOM_F1 : Atom format 1.; E > Idx:94; ID:12; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000AAAABAF907E8; > Idx:104; ID:12; I_TRACE_ON : Trace On. > Idx:105; ID:12; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x0000FFFFAEE105E8; Ctxt: AArch64,EL0, NS; > Idx:116; ID:12; I_ATOM_F1 : Atom format 1.; E > Idx:117; ID:12; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000FFFFAEE404E4; > > 0x740(a)perf.data [0x8]: event: 68 > . > . ... raw event: size 8 bytes > . 0000: 44 00 00 00 00 00 08 00 D....... > > 0x740 [0x8]: PERF_RECORD_FINISHED_ROUND > > Aggregated stats: (excludes AUX area (e.g. instruction trace) decoded / synthesized events) > TOTAL events: 22 > COMM events: 2 ( 9.1%) > EXIT events: 1 ( 4.5%) > MMAP2 events: 5 (22.7%) > AUX events: 3 (13.6%) > ITRACE_START events: 1 ( 4.5%) > ATTR events: 2 ( 9.1%) > FINISHED_ROUND events: 1 ( 4.5%) > ID_INDEX events: 1 ( 4.5%) > AUXTRACE_INFO events: 1 ( 4.5%) > AUXTRACE events: 1 ( 4.5%) > THREAD_MAP events: 1 ( 4.5%) > CPU_MAP events: 1 ( 4.5%) > TIME_CONV events: 1 ( 4.5%) > FINISHED_INIT events: 1 ( 4.5%) > > > perf annotate -v 2>&1 | tee > build id event received for [kernel.kallsyms]: 992c7046fc25c1546a5d8964379f9e2b8a969515 [20] > build id event received for /home/root/main: 70180e5f45591089669808f03ecf6c82d526ec86 [20] > build id event received for [vdso]: eb5fc38014e87cf51cc0897695f4d46bb153f346 [20] > build id event received for /home/root/libcstest.so.1.0: a6a6d7ec171f451670e7a8a08d422d2227588ac3 [20] > > > perf script -v 2>&1 | tee > build id event received for [kernel.kallsyms]: 992c7046fc25c1546a5d8964379f9e2b8a969515 [20] > build id event received for /home/root/main: 70180e5f45591089669808f03ecf6c82d526ec86 [20] > build id event received for [vdso]: eb5fc38014e87cf51cc0897695f4d46bb153f346 [20] > build id event received for /home/root/libcstest.so.1.0: a6a6d7ec171f451670e7a8a08d422d2227588ac3 [20] > Samples for 'cs_etm/@tmc_etf0/u' event do not have TIME attribute set. Skipping 'time' field. > Samples for 'cs_etm/@tmc_etf0/u' event do not have CPU attribute set. Skipping 'cpu' field. > Samples for 'branches:uH' event do not have TIME attribute set. Skipping 'time' field. > Samples for 'branches:uH' event do not have CPU attribute set. Skipping 'cpu' field. > main 838 1 branches:uH: 0 [unknown] ([unknown]) => ffffaee105a8 [unknown] (/home/root/libcstest.so.1.0) > main 838 1 branches:uH: ffffaee105b4 [unknown] (/home/root/libcstest.so.1.0) => ffffaee105d0 [unknown] (/home/root/libcstest.so.1.0) > main 838 1 branches:uH: ffffaee105d8 [unknown] (/home/root/libcstest.so.1.0) => ffffaee105b8 [unknown] (/home/root/libcstest.so.1.0) > main 838 1 branches:uH: ffffaee105d8 [unknown] (/home/root/libcstest.so.1.0) => ffffaee105b8 [unknown] (/home/root/libcstest.so.1.0) > main 838 1 branches:uH: ffffaee105d8 [unknown] (/home/root/libcstest.so.1.0) => ffffaee105b8 [unknown] (/home/root/libcstest.so.1.0) > main 838 1 branches:uH: ffffaee105d8 [unknown] (/home/root/libcstest.so.1.0) => ffffaee105b8 [unknown] (/home/root/libcstest.so.1.0) > main 838 1 branches:uH: ffffaee105d8 [unknown] (/home/root/libcstest.so.1.0) => ffffaee105b8 [unknown] (/home/root/libcstest.so.1.0) > main 838 1 branches:uH: ffffaee105e4 [unknown] (/home/root/libcstest.so.1.0) => 0 [unknown] ([unknown]) > main 838 1 branches:uH: 0 [unknown] ([unknown]) => ffffaee105e8 [unknown] (/home/root/libcstest.so.1.0) > > > Thanks, > Radhey > >> >> Or does something like this work: >> >> $ echo "12345" | addr2line -e \ >> ~/.debug/.build- >> id/b7/b30ba2c0f618615a8d32d86813718bb2fdb567/debug >> >> fpioconst.c:? >> >> I also just set the path to objdump directly rather than with a variable, but I >> assume XTOOL_PATH is set? Although I think it must be because you get a >> different error if objdump is missing. >> >> -d /usr/bin/aarch64-linux-gnu-objdump >> >> James >> >>> >>> >>> >>> >>>> ARM CoreSight Trace Data Assembler Dump >>>> >>>> addr2line /home/root/libcstest.so.1.0: could not read first record >>>> >>>> main 748/748 [0000] 0.000000000 >>>> ffffad8c05d8 /home/root/libcstest.so.1.0 >>>> >>>> addr2line /home/root/libcstest.so.1.0: could not send request >>>> >>>> main 748/748 [0000] 0.000000000 >>>> ffffad8c05d8 >>>> >>>> addr2line /home/root/libcstest.so.1.0: could not send request >>>> >>>> main 748/748 [0000] 0.000000000 >>>> ffffad8c05d8 >>>> >>>> addr2line /home/root/libcstest.so.1.0: could not send request >>>> >>>> main 748/748 [0000] 0.000000000 >>>> ffffad8c05d8 >>>> >>>> addr2line /home/root/libcstest.so.1.0: could not send request >>>> >>>> main 748/748 [0000] 0.000000000 >>>> ffffad8c05d8 >>>> >>>> addr2line /home/root/libcstest.so.1.0: could not send request >>>> >>>> main 748/748 [0000] 0.000000000 >>>> ffffad8c05e4 >>>> >>>> End >>>> >>>> tools/perf/perf report -D >>>> >>>> <snip> >>>> >>>> 0x680 [0x30]: PERF_RECORD_AUXTRACE size: 0x90 offset: 0 ref: >>>> 0x2890bdbd7cad6b6f idx: 0 tid: 748 cpu: -1 >>>> >>>> . ... CoreSight ETMV4I Trace data: size 0x20 bytes >>>> >>>> Idx:0; ID:10; I_ASYNC : Alignment Synchronisation. >>>> >>>> Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 >>>> } >>>> >>>> . ... CoreSight ETMV4I Trace data: size 0x20 bytes >>>> >>>> Idx:32; ID:10; I_ASYNC : Alignment Synchronisation. >>>> >>>> Idx:44; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 >>>> } >>>> >>>> . ... CoreSight ETMV4I Trace data: size 0x50 bytes >>>> >>>> Idx:64; ID:10; I_ASYNC : Alignment Synchronisation. >>>> >>>> Idx:76; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 >>>> } >>>> >>>> Idx:81; ID:10; I_TRACE_ON : Trace On. >>>> >>>> Idx:82; ID:10; I_ADDR_CTXT_L_64IS0 : Address & Context, >>>> Long, 64 bit, IS0.; Addr=0x0000FFFFAD8C05A8; Ctxt: AArch64,EL0, NS; >>>> >>>> Idx:92; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEN >>>> >>>> Idx:93; ID:10; I_ATOM_F1 : Atom format 1.; E >>>> >>>> Idx:94; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, >>>> IS0.; Addr=0x0000AAAAAC9107E8; >>>> >>>> Idx:104; ID:10; I_TRACE_ON : Trace On. >>>> >>>> Idx:105; ID:10; I_ADDR_CTXT_L_64IS0 : Address & Context, >>>> Long, 64 bit, IS0.; Addr=0x0000FFFFAD8C05E8; Ctxt: AArch64,EL0, NS; >>>> >>>> Idx:116; ID:10; I_ATOM_F1 : Atom format 1.; E >>>> >>>> Idx:117; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, >>>> IS0.; Addr=0x0000FFFFAD8EB4E4; >>>> >>>> 0x740(a)perf.data <mailto:0x740@perf.data> [0x8]: event: 68 >>>> >>>> . >>>> >>>> . ... raw event: size 8 bytes >>>> >>>> . 0000: 44 00 00 00 00 00 08 00 D....... >>>> >>>> 0x740 [0x8]: PERF_RECORD_FINISHED_ROUND >>>> >>>> Aggregated stats: (excludes AUX area (e.g. instruction trace) decoded >>>> / synthesized events) >>>> >>>> Thanks, >>>> >>>> Radhey >>>> >>> >>> _______________________________________________ >>> CoreSight mailing list -- coresight(a)lists.linaro.org To unsubscribe >>> send an email to coresight-leave(a)lists.linaro.org

2 years, 1 month

Re: [PATCH] coresight: etm3x: convert struct etm_drvdata's spinlock to raw_spinlock

by James Clark

On 11/07/2023 15:05, Greg Kroah-Hartman wrote: > On Tue, Jul 11, 2023 at 03:05:36PM +0800, quanyang.wang(a)windriver.com wrote: >> From: Quanyang Wang <quanyang.wang(a)windriver.com> >> >> For PREEMPT_RT kernel, spinlock_t locks become sleepable. The functions >> etm_dying_cpu and etm_starting_cpu which call spin_lock/unlock run in >> an irq-disabled context, this will trigger the following calltrace: >> >> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 >> in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 25, name: migration/1 >> preempt_count: 1, expected: 0 >> RCU nest depth: 0, expected: 0 >> 1 lock held by migration/1/25: >> #0: 82a7587c (&drvdata->spinlock){....}-{2:2}, at: etm_dying_cpu+0x28/0x54 >> Preemption disabled at: >> [<801ec760>] cpu_stopper_thread+0x94/0x120 >> CPU: 1 PID: 25 Comm: migration/1 Not tainted 6.1.35-rt10-yocto-preempt-rt #30 >> Hardware name: Xilinx Zynq Platform >> Stopper: multi_cpu_stop+0x0/0x174 <- __stop_cpus.constprop.0+0x48/0x88 >> unwind_backtrace from show_stack+0x18/0x1c >> show_stack from dump_stack_lvl+0x58/0x70 >> dump_stack_lvl from __might_resched+0x14c/0x1c0 >> __might_resched from rt_spin_lock+0x4c/0x84 >> rt_spin_lock from etm_dying_cpu+0x28/0x54 >> etm_dying_cpu from cpuhp_invoke_callback+0x140/0x33c >> cpuhp_invoke_callback from __cpuhp_invoke_callback_range+0xa4/0x104 >> __cpuhp_invoke_callback_range from take_cpu_down+0x7c/0xa8 >> take_cpu_down from multi_cpu_stop+0x15c/0x174 >> multi_cpu_stop from cpu_stopper_thread+0x9c/0x120 >> cpu_stopper_thread from smpboot_thread_fn+0x31c/0x360 >> smpboot_thread_fn from kthread+0x100/0x124 >> kthread from ret_from_fork+0x14/0x2c >> >> Convert struct etm_drvdata's spinlock to raw_spinlock to fix it. > > wait, why will a raw_spinlock fix this? Why not fix the root problem > here, that of calling these locks inproperly in irq context? > > How is changing to a raw_spinlock going to fix the above splat? > > thanks, > > greg k-h > If it's just etm_starting_cpu() and etm_dying_cpu() as mentioned in the commit message then can those spinlocks be removed? Surely there can't be any concurrent access to the per-cpu data when the hotplug callbacks are called? James > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

2 years, 1 month

Re: Perf + Opencsd (aarch64) Off Target Trace Decoding shows "could not read first record/send request"

by Suzuki K Poulose

On 11/07/2023 10:26, Pandey, Radhey Shyam wrote: > Hi all, > > I am trying off Target Trace Decoding using arm-cs-trace-disasm.py but > it doesn’t show > > proper disassembly. There is unexpected warning "could not read first > record". > > Any pointers on what the issue could be? > > Meanwhile I am trying to do trace decoding on aarch64 target and see if > that helps. > > I have taken simple example mentioned in [1]. > > [1]: > http://events17.linuxfoundation.org/sites/events/files/slides/ELC-E16.pdf <http://events17.linuxfoundation.org/sites/events/files/slides/ELC-E16.pdf> > > #include int coresight_test1(int val); > > int main(void) { > > int val; val = coresight_test1(10); > > printf("val: %d\n", val); > > return 0; > > } > > perf record -e cs_etm/@tmc_etf0/u --filter > 'filter0x5a8/0x5e4(a)/home/root/libcstest.so.1.0' --per-thread ./main > > tar czf cs_example.tgz perf.data ~/.debug > > Off Target Trace Decoding: “perf report” > > tar xf cs_example.tgz > > $ rm -rf ~/.debug // remove previous trace data > > $ cp -dpR .debug ~/ // copy the current trace data > > $ perf report --stdio > > linux-xlnx/tools/perf/perf --exec-path= <snip>/linux-xlnx/tools/perf > script tools/perf/scripts/python/arm-cs-trace-disasm.py -- -d > ${XTOOL_PATH}/aarch64-linux-gnu-objdump -v > I believe the perf script doesn't work with coresight trace decoding as we need a two pass approach for decoding the stream for figuring out the parameters for the queues. James Clark can give you the exact reason. Suzuki > ARM CoreSight Trace Data Assembler Dump > > addr2line /home/root/libcstest.so.1.0: could not read first record > > main 748/748 [0000] 0.000000000 > ffffad8c05d8 /home/root/libcstest.so.1.0 > > addr2line /home/root/libcstest.so.1.0: could not send request > > main 748/748 [0000] 0.000000000 ffffad8c05d8 > > addr2line /home/root/libcstest.so.1.0: could not send request > > main 748/748 [0000] 0.000000000 ffffad8c05d8 > > addr2line /home/root/libcstest.so.1.0: could not send request > > main 748/748 [0000] 0.000000000 ffffad8c05d8 > > addr2line /home/root/libcstest.so.1.0: could not send request > > main 748/748 [0000] 0.000000000 ffffad8c05d8 > > addr2line /home/root/libcstest.so.1.0: could not send request > > main 748/748 [0000] 0.000000000 ffffad8c05e4 > > End > > tools/perf/perf report -D > > <snip> > > 0x680 [0x30]: PERF_RECORD_AUXTRACE size: 0x90 offset: 0 ref: > 0x2890bdbd7cad6b6f idx: 0 tid: 748 cpu: -1 > > . ... CoreSight ETMV4I Trace data: size 0x20 bytes > > Idx:0; ID:10; I_ASYNC : Alignment Synchronisation. > > Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > > . ... CoreSight ETMV4I Trace data: size 0x20 bytes > > Idx:32; ID:10; I_ASYNC : Alignment Synchronisation. > > Idx:44; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > > . ... CoreSight ETMV4I Trace data: size 0x50 bytes > > Idx:64; ID:10; I_ASYNC : Alignment Synchronisation. > > Idx:76; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 } > > Idx:81; ID:10; I_TRACE_ON : Trace On. > > Idx:82; ID:10; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, > 64 bit, IS0.; Addr=0x0000FFFFAD8C05A8; Ctxt: AArch64,EL0, NS; > > Idx:92; ID:10; I_ATOM_F6 : Atom format 6.; EEEEEEN > > Idx:93; ID:10; I_ATOM_F1 : Atom format 1.; E > > Idx:94; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; > Addr=0x0000AAAAAC9107E8; > > Idx:104; ID:10; I_TRACE_ON : Trace On. > > Idx:105; ID:10; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, > 64 bit, IS0.; Addr=0x0000FFFFAD8C05E8; Ctxt: AArch64,EL0, NS; > > Idx:116; ID:10; I_ATOM_F1 : Atom format 1.; E > > Idx:117; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; > Addr=0x0000FFFFAD8EB4E4; > > 0x740(a)perf.data <mailto:0x740@perf.data> [0x8]: event: 68 > > . > > . ... raw event: size 8 bytes > > . 0000: 44 00 00 00 00 00 08 00 D....... > > 0x740 [0x8]: PERF_RECORD_FINISHED_ROUND > > Aggregated stats: (excludes AUX area (e.g. instruction trace) decoded / > synthesized events) > > Thanks, > > Radhey >

2 years, 1 month

Re: [PATCH] perf build: Fix library not found error when using CSLIBS

by Arnaldo Carvalho de Melo

Em Tue, Jul 11, 2023 at 08:28:31AM +0000, Pandey, Radhey Shyam escreveu: > > -----Original Message----- > > From: James Clark <james.clark(a)arm.com> > > Sent: Friday, July 7, 2023 9:16 PM > > To: linux-perf-users(a)vger.kernel.org; Pandey, Radhey Shyam > > <radhey.shyam.pandey(a)amd.com> > > Cc: coresight(a)lists.linaro.org; James Clark <james.clark(a)arm.com>; Peter > > Zijlstra <peterz(a)infradead.org>; Ingo Molnar <mingo(a)redhat.com>; > > Arnaldo Carvalho de Melo <acme(a)kernel.org>; Mark Rutland > > <mark.rutland(a)arm.com>; Alexander Shishkin > > <alexander.shishkin(a)linux.intel.com>; Jiri Olsa <jolsa(a)kernel.org>; > > Namhyung Kim <namhyung(a)kernel.org>; Ian Rogers <irogers(a)google.com>; > > Adrian Hunter <adrian.hunter(a)intel.com>; Uwe Kleine-König <uwe@kleine- > > koenig.org>; linux-kernel(a)vger.kernel.org > > Subject: [PATCH] perf build: Fix library not found error when using CSLIBS > > > > -L only specifies the search path for libraries directly provided in the link line > > with -l. Because -lopencsd isn't specified, it's only linked because it's a > > dependency of -lopencsd_c_api. Dependencies like this are resolved using > > the default system search paths or -rpath-link=... rather than -L. This means > > that compilation only works if OpenCSD is installed to the system rather than > > provided with the CSLIBS (-L) option. > > > > This could be fixed by adding -Wl,-rpath-link=$(CSLIBS) but that is less > > conventional than just adding -lopencsd to the link line so that it uses -L. - > > lopencsd seems to have been removed in commit ed17b1914978 ("perf > > tools: Drop requirement for libstdc++.so for libopencsd check") because it > > was thought that there was a chance compilation would work even if it didn't > > exist, but I think that only applies to libstdc++ so there is no harm to add it > > back. libopencsd.so and libopencsd_c_api.so would always exist together. > > > > Testing > > ======= > > > > The following scenarios now all work: > > > > * Cross build with OpenCSD installed > > * Cross build using CSLIBS=... > > * Native build with OpenCSD installed > > * Native build using CSLIBS=... > > * Static cross build with OpenCSD installed > > * Static cross build with CSLIBS=... > > > > Reported-by: Radhey Shyam Pandey <radhey.shyam.pandey(a)amd.com> > > Closes: https://lore.kernel.org/linux-arm-kernel/56905d7a-a91e-883a-b707- > > 9d5f686ba5f1(a)arm.com/ > > Link: https://lore.kernel.org/all/36cc4dc6-bf4b-1093-1c0a- > > 876e368af183(a)kleine-koenig.org/ > > Fixes: ed17b1914978 ("perf tools: Drop requirement for libstdc++.so for > > libopencsd check") > > Signed-off-by: James Clark <james.clark(a)arm.com> > > --- > > tools/perf/Makefile.config | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index > > 0609c19caabd..c5db0de49868 100644 > > --- a/tools/perf/Makefile.config > > +++ b/tools/perf/Makefile.config > > @@ -155,9 +155,9 @@ FEATURE_CHECK_LDFLAGS-libcrypto = -lcrypto ifdef > > CSINCLUDES > > LIBOPENCSD_CFLAGS := -I$(CSINCLUDES) > > endif > > -OPENCSDLIBS := -lopencsd_c_api > > +OPENCSDLIBS := -lopencsd_c_api -lopencsd > > ifeq ($(findstring -static,${LDFLAGS}),-static) > > - OPENCSDLIBS += -lopencsd -lstdc++ > > + OPENCSDLIBS += -lstdc++ > > endif > > ifdef CSLIBS > > LIBOPENCSD_LDFLAGS := -L$(CSLIBS) > > -- > > 2.34.1 > > Tested-by: Radhey Shyam Pandey <radhey.shyam.pandey(a)amd.com> > Cross compiled for aarch64 on x86_64. > > make ARCH=arm64 NO_LIBELF=1 NO_JVMTI=1 VF=1 CORESIGHT=1 -C tools/perf > > file <snip>/linux-xlnx/tools/perf/perf > perf: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), > dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, > BuildID[sha1]=ef7c524338577b14e7c0f914d882dec4d26e93a2, > for GNU/Linux 3.14.0, with debug_info, not stripped Thanks for reporting and testing, applied to perf-tools. I see no problems in my common case which is: ⬢[acme@toolbox perf-tools]$ alias m='make -k BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools -C tools/perf install-bin && git status && perf test python ; perf record -o /dev/null sleep 0.01 ; perf stat --null sleep 0.01' ⬢[acme@toolbox perf-tools]$ ⬢[acme@toolbox perf-tools]$ ldd ~/bin/perf | grep csd libopencsd_c_api.so.1 => /lib64/libopencsd_c_api.so.1 (0x00007f9c012ea000) libopencsd.so.1 => /lib64/libopencsd.so.1 (0x00007f9c00556000) ⬢[acme@toolbox perf-tools]$ - Arnaldo

2 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight