Re: GDB: etm traces decoding and breakpoints for arm targets

Hi,

On 10/31/20 8:10 PM, Zied Guermazi wrote:
> 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?

In case this has not been answered yet, there are *_raw_memory functions 
that read the actual contents of memory, without hiding breakpoint 
instructions.

Maybe those will be useful to you?

gdb/target.c:target_read_raw_memory (...)

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

I'm afraid not.

> do you have any other idea for handling this situation?

Breakpoint instructions shouldn't appear in the execution trace history 
I suppose. So maybe just filter out the breakpoint instructions in some way?

You did mention there is some corruption though, so I don't know if 
filtering/adjusting the history will fix the corruption.