hi,

while testing the implementation in gdb of branch tracing on arm 
processors using etm, I faced the the situation where a breakpoint was 
set, was hit and then the execution of the program was continued.  While 
decoding generated traces,  I got the address of the breakpoint 
(0x400552) executed twice, and then the following address (0x400554) 
also executed twice. the instruction at (0x400554) is a BL ( a function 
call) and the second execution corrupts the function history.

here is a dump of generated trace elements


---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400552
end addr   = 0x400554
instructions count = 1
last_i_type: OCSD_INSTR_OTHER
last_i_subtype: OCSD_S_INSTR_NONE
last instruction was executed
last instruction size: 2
---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400552
end addr   = 0x400554
instructions count = 1
last_i_type: OCSD_INSTR_OTHER
last_i_subtype: OCSD_S_INSTR_NONE
last instruction was executed
last instruction size: 2
---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400554
end addr   = 0x400558
instructions count = 1
last_i_type: OCSD_INSTR_BR
last_i_subtype: OCSD_S_INSTR_BR_LINK
last instruction was executed
last instruction size: 4
---------------------------------
trace_chan_id: 18
isa: CS_ETM_ISA_T32
start addr = 0x400554
end addr   = 0x400558
instructions count = 1
last_i_type: OCSD_INSTR_BR
last_i_subtype: OCSD_S_INSTR_BR_LINK
last instruction was executed
last instruction size: 4

the explanation I have for this behavior is that :

-when setting the software breakpoint, the memory content of the 
instruction (at 0x400552) was altered to the instruction BKPT,

-when the breakpoint was hit, the original opcode was set at (0x400552) 
and a BKPT was set to the next instruction address (0x400554), then the 
execution was continued

-when the second breakpoint (0x400554) was hit, the a BKPT opcode was 
set at (0x400552) and the original opcode was set at (0x400554) then the 
execution was continued

I am using the function "int target_read_code (CORE_ADDR memaddr, 
gdb_byte *myaddr, ssize_t len)" to give program memory content to the 
decoder. so the collected etm traces are correct, but, as memory was 
altered in between, the decoder is "cheated".

I need to identify the re-execution of code due to breakpoint handling, 
and roll back its impact on etm decoding.

is there a mean to get the actual content of program memory including 
patched addresses?

is there a means of getting the history of patched addresses during the 
debugging of a program?

what is the type and subtype of a BKPT instruction in a decoded trace 
elements?

do you have any other idea for handling this situation?


I am attaching the source code of the program as well as the 
disassembled binary. the code was compiled as an application running on 
linux on an ARMv7 A (STM32MP157 SoC). the breakpoint was set at line 43 
in the source code (line 238 in the disassembled code)


Kind Regards

Zied Guermazi