On Mon, Oct 08, 2018 at 09:49:34AM +0100, Mike Leach wrote:
[...]
- 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.
Yeah, so just want to confirm how we can distinguish the function call for 'b func_name'? E.g. I checked a bit in ARM-TF, there have some function calls are using 'b func_name' for function call and don't need to jump back to caller [1].
Do I miss any other types of function call? I checked doc 'ARMv8 Instruction Set Overview', program counter cannot be directly changed for function call in ARMv8.
For v8 that is true. Not so sure for v7. I think you can assume that any b+link is a function call. For B <address> and B.<cond> <address> it is impossible to be certain from just the trace data - these could be function calls or simply jumps for loop operations in a single function. You can either assume all of these are not function calls, or use other information (e.g. symbol infomation ) from the source files.
Thanks for suggestion, using symbol info will be more accurate, will look into this.
[...]
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.
Let me check more detailed info for this, especially after looked into in ETMv4 spec and in the OpenCSD code.
In OpenCSD lib it has arraies to present the exception type [2], this array is consistent with ETMv4 spec:
static const char *ARv8Excep[] = { "PE Reset", "Debug Halt", "Call", "Trap", "System Error", "Reserved", "Inst Debug", "Data Debug", "Reserved", "Reserved", "Alignment", "Inst Fault", "Data Fault", "Reserved", "IRQ", "FIQ" };But I'm not sure if the ocsd_generic_trace_elem::exception_number has the consistent meaning with upper array; e.g. if exception_number = 14, means the exception is an IRQ; I tried to dump the log, I even found there have logs including exception_number = 15, if connecting with upper array, this exception is FIQ but this doesn't make sense for me due I don't enable Trustzone related features on system so the system should have no user for FIQ.
Looking at the examples supplied with the library, I see 0x2 (call), 0xc (data fault) and 0xe (IRQ) exception types. I have checked the code in the decoder and cannot see anything that would indicate this is not operating correctly. Therefore it would suggest that if you are seeing FIQ, these are really happening, or the decode is not correctly synchronised to the start of the trace data. If not synchronised then I would expect to see lots of errors, not just unexpected FIQs.
At my side, I do see the exception number is mess from the dumped elements as below; you also could check complete dump log from [1], which is a big size log file (~764MB).
elem: elem_type=6 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=0 elem: elem_type=6 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=0 elem: elem_type=6 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=0 elem: elem_type=6 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=0 elem: elem_type=6 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=0 elem: elem_type=6 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=0 elem: elem_type=4 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=0 elem: elem_type=9 last_i_type=0 last_i_subtype=0 exception_number=0 exc=1 exc_ret=1 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=15 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=13 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=33 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=13 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=33 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=13 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=33 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=13 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=7 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=13 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=33 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=13 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=7 exc=0 exc_ret=0 elem: elem_type=5 last_i_type=1 last_i_subtype=0 exception_number=13 exc=0 exc_ret=0
[1] http://people.linaro.org/~leo.yan/opencsd_juno/elem_dump_for_exception_numbe...
Thanks, Leo Yan