Hi Mike,
On Wed, Oct 10, 2018 at 04:36:11PM +0100, Mike Leach wrote:
On Wed, 10 Oct 2018 at 04:49, Leo Yan leo.yan@linaro.org wrote:
The perf sample data contains flags to indicate the hardware trace data is belonging to which type branch instruction, thus this can be used to print out the human readable string. Arm CoreSight ETM sample data is missed to set flags and it is always set to zeros, this results in perf tool skips to print string for instruction types.
Arm CoreSight ETM supports different kind instruction of A64, A32 and T32; as the first step, this patch is to set sample flags for A64 instructions.
The brief idea for implementation is describe as below:
- For element with OCSD_GEN_TRC_ELEM_TRACE_ON type, it is taken as trace beginning packet; for element with OCSD_GEN_TRC_ELEM_NO_SYNC or OCSD_GEN_TRC_ELEM_EO_TRACE, these two kinds elements are used to set for trace end;
TRACE_ON will appear at the start of trace - but also at the restart of trace. So if you see multiple TRACE_ON without NO_SYNC or EO_TRACE, then subsequent TRACE_ON will represent a discontinuity in the trace.
Yeah, need to take care for continous TRACE_ON packets; will consider this in next patch series.
When I tried to address this comment, from the dump of elements, I found there have another strange flow which only contains NO_SYNC packet and INSTR_RANGE packets:
elem: elem_type=5 last_i_type=1 last_i_subtype=0 last_inst_cond=1 --> branch elem: elem_type=5 last_i_type=0 last_i_subtype=0 last_inst_cond=0 --> branch elem: elem_type=8 last_i_type=0 last_i_subtype=0 last_inst_cond=0 --> exception elem: elem_type=1 last_i_type=0 last_i_subtype=0 last_inst_cond=0 --> NO_SYNC elem: elem_type=5 last_i_type=1 last_i_subtype=0 last_inst_cond=1 --> branch elem: elem_type=5 last_i_type=1 last_i_subtype=0 last_inst_cond=1 --> branch
So you could see after the exception is taken, it inserts on an NO_SYNC packet and the later one packet is INSTR_RANGE packet with elem_type=5; in this case it's wrong to set trace end for NO_SYNC packet. Current code might has some wrong logic for setting 'decoder->trace_on = false' [1], but this doesn't cause any issue due now we don't use 'decoder->trace_on' actually.
[1] https://git.linaro.org/kernel/coresight.git/tree/tools/perf/util/cs-etm-deco...
For instruction range packet, mainly base on three factors to decide the branch instruction types:
elem->last_i_type elem->last_i_subtype elem->last_instr_cond
If the instruction is immediate branch but without link and return flag, we consider it as function internal branch; in fact the immediate branch also can be used to invoke the function entry, usually this is only used in assembly code to directly call a symbol and don't expect to return back; after reviewing kernel normal functions and user space programs, both of them are very seldom to use immediate branch for function call. On the other hand, if we want to decide the immediate branch is for function branch jumping or for function calling, we need to rely on the start address of next packet and check the symbol offset for the start address, this will introduce much complexity in the implementation. So for this version we simply consider immediate branch as function internal branch.
I think this is a good solution.
Thanks for reviewing.
If the instruction is immediate branch with link, it's instruction 'BL' and which is used for function call.
If the instruction is indirect branch without link, this is corresponding to instruction 'BR', this instruction usually is used for dynamic link lib with below usage; so we think it's a return instruction.
0000000000000680 <.plt>: 680: a9bf7bf0 stp x16, x30, [sp, #-16]! 684: 90000090 adrp x16, 10000 <__FRAME_END__+0xf630> 688: f947fe11 ldr x17, [x16, #4088] 68c: 913fe210 add x16, x16, #0xff8 690: d61f0220 br x17If the instruction is indirect branch with link, e.g BLR, we think it's a function call.
For function return, ARMv8 introduces a dedicated instruction 'ret', which has flag of OCSD_S_INSTR_V8_RET.
For exception packets, this patch divides into three types:
The first type of exception is caused by external logics like bus, interrupt controller, debug module or PE reset or halt; this is corresponding to flags "bcyi" which defined in doc perf-script.txt;
The second type is for system call, this is set as "bcs" by following definition in the doc;
The third type is for CPU trap, data and instruction prefetch abort, alignment abort; usually these exceptions are synchronous for CPU, so set them as "bci" type.
This part is not very certain that this patch has set right flags for them, the reason is the instruction trace decoding flags is original from Intel PT and it's briefly defined in the document: tools/perf/Documentation/perf-script.txt. But there have no more detailed information to explain these flags and their corresponding instructions.
This patch set exception related flags based on the literal meaning which described in the doc, and should refine according to reviewing.
Cc: Mathieu Poirier mathieu.poirier@linaro.org Cc: Mike Leach mike.leach@linaro.org Cc: Robert Walker robert.walker@arm.com Cc: Al Grant Al.Grant@arm.com Cc: Andi Kleen andi@firstfloor.org Cc: Adrian Hunter adrian.hunter@intel.com Cc: Arnaldo Carvalho de Melo acme@redhat.com Signed-off-by: Leo Yan leo.yan@linaro.org
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 158 ++++++++++++++++++++++++ tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 1 + tools/perf/util/cs-etm.c | 4 +- 3 files changed, 161 insertions(+), 2 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 938def6..b7cb962 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c @@ -347,6 +347,162 @@ cs_etm_decoder__buffer_trace_on(struct cs_etm_decoder *decoder, CS_ETM_TRACE_ON); }
+static void cs_etm_decoder__set_sample_flags(
const void *context,const ocsd_generic_trace_elem *elem)+{
struct cs_etm_decoder *decoder = (struct cs_etm_decoder *) context;struct cs_etm_packet *packet;static u32 exc_num;packet = &decoder->packet_buffer[decoder->tail];switch (elem->elem_type) {case OCSD_GEN_TRC_ELEM_TRACE_ON:packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_TRACE_BEGIN;break;case OCSD_GEN_TRC_ELEM_NO_SYNC:case OCSD_GEN_TRC_ELEM_EO_TRACE:packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_TRACE_END;break;case OCSD_GEN_TRC_ELEM_INSTR_RANGE:/** Immediate branch instruction without neither link nor* return flag, it's normal branch instruction within* the function.*/if (elem->last_i_type == OCSD_INSTR_BR &&elem->last_i_subtype == OCSD_S_INSTR_NONE) {packet->flags = PERF_IP_FLAG_BRANCH;if (elem->last_instr_cond)packet->flags |= PERF_IP_FLAG_CONDITIONAL;}/** Immediate branch instruction with link (e.g. BL), this is* branch instruction for function call.*/if (elem->last_i_type == OCSD_INSTR_BR &&elem->last_i_subtype == OCSD_S_INSTR_BR_LINK)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_CALL;/** Indirect branch instruction without link (e.g. BR), usually* this is used for function return, especially for functions* within dynamic link lib.*/if (elem->last_i_type == OCSD_INSTR_BR_INDIRECT &&elem->last_i_subtype == OCSD_S_INSTR_NONE)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_RETURN;/** Indirect branch instruction with link (e.g. BLR), this is* branch instruction for function call.*/if (elem->last_i_type == OCSD_INSTR_BR_INDIRECT &&elem->last_i_subtype == OCSD_S_INSTR_BR_LINK)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_CALL;/* Return instruction for function return. */if (elem->last_i_type == OCSD_INSTR_BR_INDIRECT &&elem->last_i_subtype == OCSD_S_INSTR_V8_RET)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_RETURN;break;case OCSD_GEN_TRC_ELEM_EXCEPTION:+#define OCSD_EXC_RESET 0 +#define OCSD_EXC_DEBUG_HALT 1 +#define OCSD_EXC_CALL 2 +#define OCSD_EXC_TRAP 3 +#define OCSD_EXC_SYSTEM_ERROR 4 +#define OCSD_EXC_INST_DEBUG 6 +#define OCSD_EXC_DATA_DEBUG 7 +#define OCSD_EXC_ALIGNMENT 10 +#define OCSD_EXC_INST_FAULT 11 +#define OCSD_EXC_DATA_FAULT 12 +#define OCSD_EXC_IRQ 14 +#define OCSD_EXC_FIQ 15
/** Exception number is saved and can be used for return* instruction analysis.*/exc_num = elem->exception_number;/** The exceptions are triggered by external signals* from bus, interrupt controller, debug module,* PE reset or halt.*/if (exc_num == OCSD_EXC_RESET ||exc_num == OCSD_EXC_DEBUG_HALT ||exc_num == OCSD_EXC_SYSTEM_ERROR ||exc_num == OCSD_EXC_INST_DEBUG ||exc_num == OCSD_EXC_DATA_DEBUG ||exc_num == OCSD_EXC_IRQ ||exc_num == OCSD_EXC_FIQ)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_CALL |PERF_IP_FLAG_ASYNC |PERF_IP_FLAG_INTERRUPT;/* The exception is for system call. */if (exc_num == OCSD_EXC_CALL)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_CALL |PERF_IP_FLAG_SYSCALLRET;/** The exception is introduced by trap, instruction &* data fault or alignment errors.*/if (exc_num == OCSD_EXC_TRAP ||exc_num == OCSD_EXC_ALIGNMENT ||exc_num == OCSD_EXC_INST_FAULT ||exc_num == OCSD_EXC_DATA_FAULT)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_CALL |PERF_IP_FLAG_INTERRUPT;break;
case OCSD_GEN_TRC_ELEM_EXCEPTION_RET:if (exc_num == OCSD_EXC_CALL)packet->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_RETURN |PERF_IP_FLAG_SYSCALLRET;elsepacket->flags = PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_RETURN |PERF_IP_FLAG_INTERRUPT;exc_num = -1;break;Be careful here - the exception number in the trace packet is _only_ valid for an exception packet. It is not valid on exception return as the trace has no information on why we are returning from an exception. Note that dependent of trace filtering or limits due to debug authentication, you may see an exception packet, and exception return
- but there may be other untraced exceptions between.
You may wish to save the exception type from the exception packet, for use when you see a return to the exception level that the exception packet left.
Yeah, I have noticed for this. So you could see I define variable 'exc_num' with static type, the 'exc_num' will record the exception number for exception packet and then can be used by exception return packet.
But this is not very robust for using a single variable to track exception number, especially if we consider the global tracing case which have many CPUs running and there have multiple exceptions are triggered at the meantime on different CPUs.
Just want to confirm, is it possible to use OpenCSD to track the correct exception number in the exception return packet? Seems to me this is the neat method and also can keep perf code clean.
If you think this is diffult to support in OpenCSD lib, then I can use perf data structure to track the exception number for every CPU.
[...]
Thanks, Leo Yan