hi Mike
I am compiling , running and debugging a program generated from the same source code on ARMv7 and ARMv8 processors. when a breakpoint is hit, I am using the traces to reconstruct the execution flow.
I noticed that on stm32 the decoder emits the address of the breakpoint in an OCSD_GEN_TRC_ELEM_INSTR_RANGE twice (before and after the exception), whereas it emits it only once (after the exception).
I need to have different handling according to the situation.
what can I use to distinguish both cases and handle the traces properly:
- the ETM version (v3.x vs v4.x)
- the CPU architecture (Cortex A v7 vs cortex A v8)
- the ISA of executed program (A64 vs (A32 or T32 ))
- the exception number
below are the logs
on stm32MP1 (ARMv7, cortex A7)
[btrace] ETM trace_element: index= 12, channel= 0x10, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x103f4:[0x103f6] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 13, channel= 0x10, OCSD_GEN_TRC_ELEM_EXCEPTION(excep num (0x09) ) [btrace] ETM trace_element: index= 54, channel= 0x10, OCSD_GEN_TRC_ELEM_TRACE_ON( [begin or filter]) [btrace] ETM trace_element: index= 54, channel= 0x10, OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=T32) N; 32-bit; ) [btrace] ETM trace_element: index= 60, channel= 0x10, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x103f4:[0x103f6] num_i(1) last_sz(2) (ISA=T32) E --- )
on qcom APQ8016e(ARMv8, Cortex A53)
[btrace] ETM trace_element: index= 38, channel= 0x12, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4005b4:[0x4005b8] num_i(1) last_sz(4) (ISA=A64) E --- ) [btrace] ETM trace_element: index= 38, channel= 0x12, OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x4005b8; excep num (0x06) ) [btrace] ETM trace_element: index= 112, channel= 0x16, OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) [btrace] ETM trace_element: index= 138, channel= 0x16, OCSD_GEN_TRC_ELEM_TRACE_ON( [begin or filter]) [btrace] ETM trace_element: index= 139, channel= 0x16, OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A64) EL0N; 64-bit; ) [btrace] ETM trace_element: index= 150, channel= 0x16, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4005b8:[0x4005bc] num_i(1) last_sz(4) (ISA=A64) E BR )
Kind Regards
Zied Guermazi
Hi Zied,
What you are seeing here is a difference in the way the underlying trace protocols are handling a breakpoint exception. ETMv3.x evidently emits an atom for the undefined instruction (used as breakpoint) then emits the exception branch packet. Once you restart then you have replaced the instruction with the correct one so carry on. ETM4.x you see an instruction debug exception - the program flow trace does not count this as an executed instruction and therefore it is not counted before the exception packet is emitted. You restart on the preferred return address - i.e. the address of the breakpoint, with the correct instruction - which in the v8 case appears to be a branch.
I think that the problem you have is that the two exception types are not equivalent - so you are seeing differing behaviour. I recall from our previous conversations that the v7 arch gdb is still inserting an undefined instruction as a breakpoint (as this is backward compatible?) Have you tried using an actual software break instruction here, which should result in a prefetch abort / software break exeption in ETMv3. This may give more consistent behaviour between the 2 architectures.
Regards
Mike
On Tue, 19 Jan 2021 at 03:26, Zied Guermazi zied.guermazi@trande.de wrote:
hi Mike
I am compiling , running and debugging a program generated from the same source code on ARMv7 and ARMv8 processors. when a breakpoint is hit, I am using the traces to reconstruct the execution flow.
I noticed that on stm32 the decoder emits the address of the breakpoint in an OCSD_GEN_TRC_ELEM_INSTR_RANGE twice (before and after the exception), whereas it emits it only once (after the exception).
I need to have different handling according to the situation.
what can I use to distinguish both cases and handle the traces properly:
the ETM version (v3.x vs v4.x)
the CPU architecture (Cortex A v7 vs cortex A v8)
the ISA of executed program (A64 vs (A32 or T32 ))
the exception number
below are the logs
on stm32MP1 (ARMv7, cortex A7)
[btrace] ETM trace_element: index= 12, channel= 0x10, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x103f4:[0x103f6] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 13, channel= 0x10, OCSD_GEN_TRC_ELEM_EXCEPTION(excep num (0x09) ) [btrace] ETM trace_element: index= 54, channel= 0x10, OCSD_GEN_TRC_ELEM_TRACE_ON( [begin or filter]) [btrace] ETM trace_element: index= 54, channel= 0x10, OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=T32) N; 32-bit; ) [btrace] ETM trace_element: index= 60, channel= 0x10, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x103f4:[0x103f6] num_i(1) last_sz(2) (ISA=T32) E --- )
on qcom APQ8016e(ARMv8, Cortex A53)
[btrace] ETM trace_element: index= 38, channel= 0x12, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4005b4:[0x4005b8] num_i(1) last_sz(4) (ISA=A64) E --- ) [btrace] ETM trace_element: index= 38, channel= 0x12, OCSD_GEN_TRC_ELEM_EXCEPTION(pref ret addr:0x4005b8; excep num (0x06) ) [btrace] ETM trace_element: index= 112, channel= 0x16, OCSD_GEN_TRC_ELEM_NO_SYNC( [init-decoder]) [btrace] ETM trace_element: index= 138, channel= 0x16, OCSD_GEN_TRC_ELEM_TRACE_ON( [begin or filter]) [btrace] ETM trace_element: index= 139, channel= 0x16, OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=A64) EL0N; 64-bit; ) [btrace] ETM trace_element: index= 150, channel= 0x16, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4005b8:[0x4005bc] num_i(1) last_sz(4) (ISA=A64) E BR )
Kind Regards
Zied Guermazi
--
Zied Guermazi founder
Trande UG Leuschnerstraße 2 69469 Weinheim/Germany
Mobile: +491722645127 mailto:zied.guermazi@trande.de
Trande UG Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127 Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 - Geschäftsführung: Zied Guermazi
Confidentiality Note This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited.