Hi Leo,
On Wed, 3 Oct 2018 at 15:15, leo.yan@linaro.org wrote:
Hi Mathieu, Mike,
[ + CoreSight list ]
When reviewed Andi's patch 'tools, perf, script: Add --call-trace and --call-ret-trace' [1], I found after applying this patch with CoreSight, perf fails to output two fields: one is missing to output the sample flags (e.g. 'call', 'return', 'jmp', etc) [2], another missing is failed to output the symbols [3]. The cause for the issues is CoreSight doesn't set sample flags and simply set it to zero [4].
If I understand correctly (Mathieu also mentioned to me at connect), I think before you guys have awared for this. So want to check if you have existed fixing for this in case I am doing duplicate works at here? :) Or there have some discussion and known issues so cannot enable sample flags before?
I did some investigation for these, CoreSight can set partial sample flags for A64 branch instructions with packet infos:
ocsd_generic_trace_elem::last_i_type can be used to check if the instruction is immediate branch instruction or indirect branch instruction;
ocsd_generic_trace_elem::last_i_subtype can be used to distinguish if it's link branch instruction (OCSD_S_INSTR_BR_LINK), if it's link branch instruction then this means this branch insturction is for function call;
A branch + link will be a function call, but all function calls do not have to be br+link.
if it's return branch instruction (OCSD_S_INSTR_V8_RET), then it's return instruction;
True for v8 - but other ISAs (A32 / T32) there is no explicit marking of "ret" - these can be simply mov PC. [rX] or any other instruction that updates the PC.
Otherwise (OCSD_S_INSTR_NONE), it's a simple branch instruction within the function.
No - this indicates the end of a trace range that is _not_ a branch. Could happen prior to an exception or simply due to trace filtering.
But there still have several things are not clear for me:
How can we distinguish the exception is for system call, or interrupt. The reason is we can see Intel-pt set sample flags for different values for different exception types:
PERF_IP_FLAG_INTERRUPT PERF_IP_FLAG_SYSCALLRET
I think we might can use ocsd_generic_trace_elem::exception_number to distinguish the different exception types, but I don't find any doc to clear define for this value.
The ETMv4 specification defines exception numbers - these are simply passed through directly to the output elements. So with this information the exception types flags could be set.
- I don't know if there have any info or hints in CoreSight packet can be used to indicate the branch is conditional branch or not. For Intel-pt, it can set the conditional branch instruction with flag: PERF_IP_FLAG_CONDITIONAL.
There are no indicators in the trace data of this, but the other flags such as OCSD_S_INSTR_V8_RET are generated from the code analysis as the decoder walks through the memory image matching trace waypoints to branch instructions. If required this code could be updated to mark conditional ./ not conditional as well - which would mean an updated version of the OpenCSD library.
This would also mean a change to the library ABI - either an additional field or additional enum values that the new code will have to compile against, meaning it will be incompatible with the old library source. This brings us back to another recent mailing list thread about the best way to handle the changes that have already occurred.
- I understand it's low priority to support A32 and T32 instructions, but just note here I also don't have no idea for this part.
See my comments above - some of the things will still work, but RET is harder to be certain about.
Regards
Mike
Could you give some suggestion and guidance for this? Thanks in advance.
Thanks, Leo Yan
[1] https://lore.kernel.org/patchwork/patch/987916/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool... [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool... [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...