From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by sourceware.org (Postfix) with ESMTPS id EE902384BC3C for ; Mon, 2 Nov 2020 11:59:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EE902384BC3C Received: by mail-yb1-xb32.google.com with SMTP id k138so4999221ybk.6 for ; Mon, 02 Nov 2020 03:59:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sEq2+0xhxjWwtXoiH5zBwMs0WyPDc2yVmfkB3uWQnao=; b=WxxLBZS7PTxLbCFVfJj26T7SmR2XyM0MF0zTKrB8DPDaYHWPM4CqirQ/SE/tigCYei +rDk6NrfYdV4OzXt8HJvLjryF9sRdCD8Hc32Ua43Y50I0pPTXEzEMBBUoIJJIiyPBppZ Kko310rIyayT4zNp0Y+CfTFpnmZGx/Pj8NiQ1tEoKK1D251vaku/r10xyemrYyD6pyI0 U8Ipy1SCsDhxQ/O+wxDQcu/+HevMLnS96lUTjVKQT2ksX6ATAG9hzGfJbJb57NdGkhZK VSiEUzvMPl1KjtOrAlgPYvBL6uT8gkndnUOXKbiMjpshDjw3INPbnsXOFOwUf9t3ET0m KQ8w== X-Gm-Message-State: AOAM531khGpxliVMttk/cAXYzQuRdNRvXN2WVESdwzW56atS+WyNCa9B gmywjXvVVq3fNwOcDY4j2khjITi/p6gHi6HTCUjS8w== X-Google-Smtp-Source: ABdhPJzqKJKc+twPOApedcAmTqOzipJFvIH+kbG6t+MCtedywf/TPM9msoqcKO+SBJUReDjv3mL8m/1EmdlRBSESUY4= X-Received: by 2002:a25:3415:: with SMTP id b21mr21284438yba.440.1604318399428; Mon, 02 Nov 2020 03:59:59 -0800 (PST) MIME-Version: 1.0 References: <8288e8d1-f5e7-5b69-5bac-370a37177097@trande.de> In-Reply-To: <8288e8d1-f5e7-5b69-5bac-370a37177097@trande.de> From: Mike Leach Date: Mon, 2 Nov 2020 11:59:48 +0000 Message-ID: Subject: Re: GDB: etm traces decoding and breakpoints for arm targets To: Zied Guermazi Cc: Coresight ML , toolchain@lists.linaro.org, gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 12:00:02 -0000 Hi Zeid, On Sat, 31 Oct 2020 at 23:11, 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? > > 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? > I can only really comment on this question. The type / subtype information in the output from the decoder is generated from the decoder walking the memory image of the executed trace - not from the trace packets themselves. The decoder classifies instructions according to how they will affect trace flow with the "other" category being set for the majority of instructions. The categories are: other, branch, indirect branch, ISB / DSB / DMB / WFI / WFE. These are important in program flow trace (PTM 1.x, ETM 4.x) as these determine which instruction we attach the E/N atoms to. BKPT will be classified as "other", if it is seen, as it has no effect on normal program flow. It will cause an exception which has a specific trace packet format. Regards Mike > 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 > > _______________________________________________ > CoreSight mailing list > CoreSight@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/coresight -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK