CoreSight August 2017

coresight@lists.linaro.org

11 participants
16 discussions

Start a nNew thread

Question for openCSD - open soruce Coresight Trace Decode

by 임영재

6 years, 6 months

[PATCH 1/2] perf inject: correct recording of branch address and destination

by Sebastian Pop

ARM ETM traces contain packets of executed instructions. The addresses recorded in the trace correspond to the beginning and one instruction past the end of the block of executed instructions. In order to record the address and destination of executed branches, keep track of two packets: the jump occurs from the last executed instruction of the previous packet to the address of the first instruction in the current packet. Signed-off-by: Sebastian Pop <s.pop(a)samsung.com> Signed-off-by: Brian Rzycki <b.rzycki(a)samsung.com> --- tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++ tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 1 + tools/perf/util/cs-etm.c | 91 +++++++++++++++++-------- 3 files changed, 75 insertions(+), 29 deletions(-) diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c index b4cbf4c..6164bfe 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c @@ -143,6 +143,18 @@ static int cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder, decoder->packet_buffer[et].sample_type = sample_type; decoder->packet_buffer[et].start_addr = elem->st_addr; decoder->packet_buffer[et].end_addr = elem->en_addr; + switch (elem->last_i_type) { + case OCSD_INSTR_BR: + case OCSD_INSTR_BR_INDIRECT: + decoder->packet_buffer[et].last_instruction_is_branch = true; + break; + case OCSD_INSTR_OTHER: + case OCSD_INSTR_ISB: + case OCSD_INSTR_DSB_DMB: + default: + decoder->packet_buffer[et].last_instruction_is_branch = false; + break; + } decoder->packet_buffer[et].exc = false; decoder->packet_buffer[et].exc_ret = false; decoder->packet_buffer[et].cpu = *((int*)inode->priv); diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h index d15a288..4fd5a9b 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h @@ -49,6 +49,7 @@ struct cs_etm_packet { enum cs_etm_sample_type sample_type; uint64_t start_addr; uint64_t end_addr; + bool last_instruction_is_branch; bool exc; bool exc_ret; int cpu; diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 8270203..c99b728 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -104,6 +104,10 @@ struct cs_etm_queue { * inserted. */ size_t last_branch_pos; + /* + * A pointer to the last and current decoded packets. + */ + struct cs_etm_packet *prev_packet, *packet; }; static int cs_etm__get_trace(struct cs_etm_buffer *buff, struct cs_etm_queue *etmq); @@ -226,6 +230,8 @@ static void cs_etm__free_queue(void *priv) zfree(&etmq->event_buf); zfree(&etmq->last_branch); zfree(&etmq->last_branch_rb); + zfree(&etmq->prev_packet); + zfree(&etmq->packet); zfree(&etmq->chain); free(etmq); } @@ -392,6 +398,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm, if (etm->synth_opts.last_branch) { size_t sz = sizeof(struct branch_stack); + size_t szp = sizeof(struct cs_etm_packet); sz += etm->synth_opts.last_branch_sz * sizeof(struct branch_entry); @@ -401,6 +408,12 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm, etmq->last_branch_rb = zalloc(sz); if (!etmq->last_branch_rb) goto out_free; + etmq->prev_packet = zalloc(szp); + if (!etmq->prev_packet) + goto out_free; + etmq->packet = zalloc(szp); + if (!etmq->packet) + goto out_free; } etmq->event_buf = malloc(PERF_SAMPLE_MAX_SIZE); @@ -451,6 +464,8 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm, zfree(&etmq->event_buf); zfree(&etmq->last_branch); zfree(&etmq->last_branch_rb); + zfree(&etmq->prev_packet); + zfree(&etmq->packet); zfree(&etmq->chain); free(etmq); return NULL; @@ -594,8 +609,7 @@ static inline void cs_etm__reset_last_branch_rb(struct cs_etm_queue *etmq) etmq->last_branch_rb->nr = 0; } -static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq, - struct cs_etm_packet *packet) +static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq) { struct branch_stack *bs = etmq->last_branch_rb; struct branch_entry *be; @@ -611,10 +625,16 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq, etmq->last_branch_pos -= 1; - be = &bs->entries[etmq->last_branch_pos]; - be->from = packet->start_addr; - be->to = packet->end_addr; - /* No support for mispredict */ + be = &bs->entries[etmq->last_branch_pos]; + + /* + * The FROM address needs to be the instruction before the end of the + * packet at END_ADDR: substract from END_ADDR the size of the last + * instruction: 4 bytes. + */ + be->from = etmq->prev_packet->end_addr - 4; + be->to = etmq->packet->start_addr; + /* No support for mispredict. */ be->flags.mispred = 0; be->flags.predicted = 1; @@ -721,13 +741,13 @@ static struct cs_etm_cache_entry *cs_etm__cache_lookup(struct dso *dso, } #endif -static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq, - struct cs_etm_packet *packet) +static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq) { int ret = 0; struct cs_etm_auxtrace *etm = etmq->etm; union perf_event *event = etmq->event_buf; struct perf_sample sample = {.ip = 0,}; + struct cs_etm_packet *packet = etmq->packet; uint64_t start_addr = packet->start_addr; uint64_t end_addr = packet->end_addr; @@ -941,17 +961,18 @@ static int cs_etm__synth_events(struct cs_etm_auxtrace *etm, static int cs_etm__sample(struct cs_etm_queue *etmq, int *cpu) { - //const struct cs_etm_state *state = etmq->state; - struct cs_etm_packet packet; - //struct cs_etm_auxtrace *etm = etmq->etm; - int err; + struct cs_etm_auxtrace *etm = etmq->etm; + struct cs_etm_packet *tmp; + int err = cs_etm_decoder__get_packet(etmq->decoder, etmq->packet); - err = cs_etm_decoder__get_packet(etmq->decoder,&packet); - // if there is no sample, it returns err = -1, no real error + /* + * If there is no sample, it returns err = -1, no real error. + */ if (err) return err; - if (etmq->etm->synth_opts.last_branch) { - *cpu = packet.cpu; + + if (etm->synth_opts.last_branch) { + *cpu = etmq->packet->cpu; /* * FIXME: as the trace sampling does not work for now, (for @@ -961,17 +982,30 @@ static int cs_etm__sample(struct cs_etm_queue *etmq, int *cpu) * should be rewritten as "if reached sampling period". */ if (etmq->last_branch_rb->nr == - etmq->etm->synth_opts.last_branch_sz) { - err = cs_etm__synth_instruction_sample(etmq, &packet); + etm->synth_opts.last_branch_sz) { + err = cs_etm__synth_instruction_sample(etmq); if (err) return err; } - cs_etm__update_last_branch_rb(etmq, &packet); - } else if (packet.sample_type & CS_ETM_RANGE) { - err = cs_etm__synth_instruction_sample(etmq,&packet); - if (err) - return err; - } + /* + * Record a branch when the last instruction in PREV_PACKET is a + * branch. + */ + if (etmq->prev_packet->last_instruction_is_branch) + cs_etm__update_last_branch_rb(etmq); + + /* + * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for + * the next incoming packet. + */ + tmp = etmq->packet; + etmq->packet = etmq->prev_packet; + etmq->prev_packet = tmp; + } else if (etmq->packet->sample_type & CS_ETM_RANGE) { + err = cs_etm__synth_instruction_sample(etmq); + if (err) + return err; + } return 0; } @@ -1016,15 +1050,14 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq, u64 *timestamp) * buffer at the end of the trace. */ if (etmq->etm->synth_opts.last_branch) { - struct cs_etm_packet packet; struct branch_stack *bs = etmq->last_branch_rb; struct branch_entry *be = &bs->entries[etmq->last_branch_pos]; - packet.cpu = cpu; - packet.start_addr = be->from; - packet.end_addr = be->to; + etmq->packet->cpu = cpu; + etmq->packet->start_addr = be->to; + etmq->packet->end_addr = be->to + 4; - err = cs_etm__synth_instruction_sample(etmq, &packet); + err = cs_etm__synth_instruction_sample(etmq); if (err) return err; } -- 2.7.4

6 years, 7 months

Re: CoreSight Perf Decoder

by Mathieu Poirier

On 26 July 2017 at 09:38, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: > Hello Mathieu, Mike > > Good day, > > I have a few questions about perf and decoder road maps and bug fixes. Here > is a list of issues that > > I have found out. I like to know if these are known problems and what is the > process to get them resolved. > > > > 1) Snapshot mode (option –S) does not work. Ideally we need to run perf > record with options –a and –S > > to trace in snapshot mode on all the cores That shouldn't be hard to fix - I'll open a card for this. > > > > 2) Perf record with option –C also does not work. We want, in some cases, > limit the trace to a subset of cores I've been trying to fix this for a while but have failed completely. To address the issue I don't see any other way than to change the perf ABI between user and kernel space, something that has been rejected by the community in no uncertain terms. I will sit down with Peter Z. at Linux Plumbers in September to see how best to move forward. This is very high on my list of priorities. It is also the first step in supporting a multi-sink topology. > > > > 3) Time and cycle information is in the raw trace but perf decoder cannot > decode it That one is for Mike. It will also require modifications to the perf tools. > > > > Thanks for all your help. Any time, Mathieu > > > > Regards, Reza

6 years, 7 months

OpenCSD support for ETM v4.2

by Sebastian Pop

Hi Mike, I see the following text in https://github.com/Linaro/OpenCSD Current support: ETMv4 (v4.1) instruction trace - packet processing and packet decode. Are there plans to support ETM v4.2 in the OpenCSD decoder? Thanks, Sebastian

6 years, 7 months

OpenCSD ETMv4 decode patch

by Thierry Laviron

Hi, Following my previous email (which you might not have received yet, because the attached snapshot was slightly over the size limit), I have written a small patch to address the issue I found with ETMv4 decoding. For clarity, the issue I encountered was that in EtmV4ITrcPkt::updateShortAddress, when the v_addr field is computed, it uses the old value (which is supposed to be the last broadcast address, according to the documentation). However, when an Exact Match packet is output, the specification says that the matched address is pushed at the front of the address queue. The v_addr field looks to me like it is the top of the address queue, so should be updated in EtmV4ITrcPacket::setAddressExactMatch, which is currently not done. The patch I wrote replicates the address queue in the EtmV4ITrcPacket class, to update the last broadcast address accordingly when reading an exact match. There is a bit of redundancy, because it is also done in the TrcPktDecodeEtmV4I class, but it seems to fix the problem. You will find the patch attached to this email. Below is the output for the section that showed an incorrect output. Idx:4248; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DC2DC ~[0xDC] Idx:4250; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4251; ID:12; I_ATOM_F2 : Atom format 2.; EE Idx:4252; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D004C ~[0x1004C] Idx:4256; ID:12; I_ATOM_F1 : Atom format 1.; E Idx:4257; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCC6C ~[0x1CC6C] Idx:4260; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4261; ID:12; I_ATOM_F3 : Atom format 3.; NNE Idx:4262; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4263; ID:12; I_ATOM_F2 : Atom format 2.; EE Idx:4264; ID:12; I_ADDR_MATCH : Exact Address Match., [1] Idx:4265; ID:12; I_ATOM_F1 : Atom format 1.; E Idx:4266; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D00F4 ~[0xF4] The last address is constructed from 0x004D004C, which is at the top of the address queue after the Exact Match. Before the patch, it was constructed from 0x004DCC6C, which was at the top of the address queue *before* the Exact Match, and at index 1 after. I hope you can add this patch to the library at some point, or a modified version of it. Best regards, Thierry Laviron IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 8 months

OpenCSD bug in ETMv4 decoder

by Thierry Laviron

Hi, I think we have discovered a bug in the ETMv4 decoder, when there is an 'exact match' packet followed by an address packet that is not 64 bit long. Here is a faulty sample: Idx:4248; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DC2DC ~[0xDC] Idx:4250; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4251; ID:12; I_ATOM_F2 : Atom format 2.; EE Idx:4252; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D004C ~[0x1004C] Idx:4256; ID:12; I_ATOM_F1 : Atom format 1.; E Idx:4257; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCC6C ~[0x1CC6C] Idx:4260; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4261; ID:12; I_ATOM_F3 : Atom format 3.; NNE Idx:4262; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4263; ID:12; I_ATOM_F2 : Atom format 2.; EE Idx:4264; ID:12; I_ADDR_MATCH : Exact Address Match., [1] Idx:4265; ID:12; I_ATOM_F1 : Atom format 1.; E Idx:4266; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCCF4 ~[0xF4] We have 3 addresses output before the exact match; at that point the state of the address queue is 0: 0x004DCC6C 1: 0x004D004C 2: 0x004DC2DC After the exact match packet, it should be 0: 0x004D004C 1: 0x004DCC6C 2: 0x004D004C This means that the next address value should be compared to 0x004D004C The next address packet is a short address, with one byte of data. It tells us bits[8:0] of the next address are 0x0F4 This means the next executed address is 0x004D00F4. However the decoder is interpreting it as 0x004DCCF4, as if it did not update the queue. Looking at the code, it appears the address queue does get properly updated on an exact match packet, however when reconstructing addresses, it uses an ocsd_etmv4_i_pkt::v_addr field; documentation says this is the "most recently broadcast address packet". This v_addr field does not get updated on an exact match packet, but if I am reading the specifications right it should. Am I right in assuming this is a bug? I have attached the snapshot that produces the bug, and the executable that produced the trace so you can check the assembly code. Best regards, Thierry IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 8 months

Re: Re: OpenCSD on Juno

by marekzmyslowski

Hello Mathieu, I've decided that currently I don't need Android. The Linux is enough. However I have another issue. I've downloaded the perf-opencsd-master branch. I run the config with the ARCH=arm64 and CROSS_COMPLIE=aarch64-linux-gnu- and added support for Versatile board. Then I compiled kernel - everything was OK. Next I built the USB using the following instruction: https://archlinuxarm.org/platforms/armv8/arm/juno (it works fine. The linux boot on the Juno). Next I copied the Image file and juno.dtb into the USB but it doesn't boot. It hangs here: initrd: address 0x0 initrd: length 0x0 PEI 1132 ms DXE 1695 ms BDS 368934875444 ms BDS 368934873448 ms BDS 1535 ms Total Time = 368934871781 ms linux: address 0x80080000 linux: length 0x1150200 fdt: address 0x9FE00000 fdt: length 0x5F54 Any idea what I'm doing wrong? Any help will be appreciated (I'm so close to have Juno + CoreSight + perf :) ) Regards Marek W dniu 2017-08-16 23:08:04 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał: > Hello Marek, > > Please CC the CoreSight mailing list when asking questions as someone > else may also be able to answer. > > First and foremost I advise using the official CoreSight kernel found > on the openCSD site [1] rather than my personal branch [2] - you > never know what you'll get with the latter. > > That being said the CoreSight kernel on the openCSD site is not an > Android kernel - it is simply a mainline kernel supplemented with > patches that haven't made their way to mainline yet. You will have to > either add the android patches to the CoreSight kernel or the other > way around (CoreSight patches on android kernel). > > Android user space is also different and does not include the > perf-tools. You will have to add them manually along with the > dependencies they require. I haven't gone through that process and as > such can't advise more on that portion. > > Get back to me with your questions if the above isn't sufficient. > > Best regards, > Mathieu > > [1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master > [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/ > > On 16 August 2017 at 14:32, marekzmyslowski > <marekzmyslowski(a)poczta.onet.pl> wrote: > > Hello Mathieu, > > > > I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12. > > Any help with this will be appreciated :) > > > > Regards > > Marek Zmysłowski >

6 years, 8 months

Re: OpenCSD on Juno

by Mathieu Poirier

Hello Marek, Please CC the CoreSight mailing list when asking questions as someone else may also be able to answer. First and foremost I advise using the official CoreSight kernel found on the openCSD site [1] rather than my personal branch [2] - you never know what you'll get with the latter. That being said the CoreSight kernel on the openCSD site is not an Android kernel - it is simply a mainline kernel supplemented with patches that haven't made their way to mainline yet. You will have to either add the android patches to the CoreSight kernel or the other way around (CoreSight patches on android kernel). Android user space is also different and does not include the perf-tools. You will have to add them manually along with the dependencies they require. I haven't gone through that process and as such can't advise more on that portion. Get back to me with your questions if the above isn't sufficient. Best regards, Mathieu [1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/ On 16 August 2017 at 14:32, marekzmyslowski <marekzmyslowski(a)poczta.onet.pl> wrote: > Hello Mathieu, > > I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12. > Any help with this will be appreciated :) > > Regards > Marek Zmysłowski

6 years, 8 months

Re: Opencsd Library.

by Mathieu Poirier

Good morning Maryem, I am enlisting Mike's help on this one. When looking for support on CoreSight I suggest you CC the mailing list - there is a lot of knowledgeable people on there that can help you. Mathieu On 11 August 2017 at 08:57, Maryem Ayadi <maryem.ayady(a)gmail.com> wrote: > Hi mathieu, > > I am working with the Opencsd library under linux in order to collect and > decode the trace. > I am using the Snapshots directory and I already decoded the trace packets > from ETB_0 using ETM and captured from juno_r1_1 using the following > command: ./tests/bin/linux64/dbg/trc_pkt_lister -ss_dir > tests/snapshots/juno_r1_1/ -decode -src_name ETB_0 . This is an extract of > the generic output packets: > > > Idx:65507; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c5dc ) > Idx:65508; ID:15; [0x95 0x3b ]; I_ADDR_S_IS0 : Address, Short, IS0.; > Addr=0x000000000040C4EC ~[0xEC] > Idx:65510; ID:15; [0xfe ]; I_ATOM_F3 : Atom format 3.; NEE > Idx:65510; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) > Idx:65475; ID:10; OCSD_GEN_TRC_ELEM_EO_TRACE() > > > Now I want to generate trace data captured with ETM and coded in assembly > language. Is that possible without using any debugger tool such as ARM's > DS-5 debugger tool ? > It would be helpful to send me any steps I should follow. > > Best regards, > Maryem Ayadi >

6 years, 8 months

Using perf+OpenCSD with v4.4 kernel

by Chunyan Zhang

Hi Mathieu, I'm trying to make Coresight along with perf and OpenCSD working in some internal project of Spreadtrum recently. As the kernel we're using in-house is v4.4.49 which doesn't support using CoreSight with perf tools, so I got the internal kernel merged with LSK4.4 [1]. Now I can collect trace with the command 'perf record -e cs_etm/(a)10003000.etb/ --per-thread uname' on an our *ARM64* platform, the 'perf' was compiled from perf-opencsd-4.12 [2]. But after operated in this way on our *32-bit ARM* platform, I received the following error: perf record -e cs_etm/(a)10003000.etb/ --per-thread uname event syntax error: 'cs_etm/(a)10003000.etb/' \___ parser error As I mentioned above the perf tool was compiled from perf-opencsd-4.12 with a 32-bit arm toolchain and kernel source code was also the same. The only possible reason I can think out is that I have to backport some patchs for supporting using ETMv3 with perf tools? Thanks, Chunyan [1] https://git.linaro.org/kernel/linux-linaro-stable.git/commit/?h=linux-linar… [2] https://github.com/Linaro/OpenCSD/commits/perf-opencsd-4.12

6 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight August 2017