From: Luis Machado <luis.machado@linaro.org>
To: Zied Guermazi <zied.guermazi@trande.de>,
coresight@lists.linaro.org, toolchain@lists.linaro.org,
gdb@sourceware.org
Subject: Re: GDB: etm traces decoding and breakpoints for arm targets
Date: Wed, 4 Nov 2020 13:04:18 -0300 [thread overview]
Message-ID: <05b117ac-8ce3-0ce7-bcf4-9d8596608a4a@linaro.org> (raw)
In-Reply-To: <8288e8d1-f5e7-5b69-5bac-370a37177097@trande.de>
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.
prev parent reply other threads:[~2020-11-04 16:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 23:10 Zied Guermazi
2020-11-02 11:59 ` Mike Leach
2020-11-02 15:52 ` Zied Guermazi
2020-11-03 11:02 ` Mike Leach
2020-11-04 16:04 ` Luis Machado [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=05b117ac-8ce3-0ce7-bcf4-9d8596608a4a@linaro.org \
--to=luis.machado@linaro.org \
--cc=coresight@lists.linaro.org \
--cc=gdb@sourceware.org \
--cc=toolchain@lists.linaro.org \
--cc=zied.guermazi@trande.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).