From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by sourceware.org (Postfix) with ESMTPS id BCD8A385DC33 for ; Wed, 4 Nov 2020 16:04:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BCD8A385DC33 Received: by mail-qv1-xf36.google.com with SMTP id dj6so6144187qvb.3 for ; Wed, 04 Nov 2020 08:04:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CcD2ior2ND8wFcmyX0jDDKt/ObfypImDtakNaSTRcPY=; b=gEjDkEOwL99bVOweEpTFSeam7HundYPWN+DkmVagB850WvaBoHrBtf0x3293wiSbAY bs+AuwuGoAvoxKRH9x2J5N4A8mg1tjp3Dwf4YSiohMbBIfvJTqNh++A9Vj/G4sV9H6/o t5NuOaN6COlFuehdMhKEWqzh5INuFrI8A+W0wNv2b3yZXo12y6cDQdHgTLpiMLbvToSq 9qdb5XUrB3oirulAyHM5/KBVZfEw533suRV+AushcXbbqF/MReF3t5y0/GHsxR2KvJdd S88QIm/WnmwnUlPB5VfUKTA9gcsb5EDqAv7lqxSZ/BdJmeXO+0mWXxQnlv1RljFEhNuw 0XaQ== X-Gm-Message-State: AOAM533n17RsEkHos7m2RZmiR4nuNv078xYnSR2wrXIscslVgUIPJdTx zYvtAM5ECuNPh0ZPfnBqZX5EzCUPGhuIng== X-Google-Smtp-Source: ABdhPJzg6YZAPlyJuZsA9BDtxckWjBhmgXcvfMJaReJofhffkO9iRtZsd2ytmuRUF/oDZBdmJuES6A== X-Received: by 2002:a0c:f70f:: with SMTP id w15mr32281568qvn.45.1604505863217; Wed, 04 Nov 2020 08:04:23 -0800 (PST) Received: from ?IPv6:2804:7f0:8284:1487:f9b0:4934:a531:9cf0? ([2804:7f0:8284:1487:f9b0:4934:a531:9cf0]) by smtp.gmail.com with ESMTPSA id l22sm405139qtq.6.2020.11.04.08.04.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Nov 2020 08:04:22 -0800 (PST) Subject: Re: GDB: etm traces decoding and breakpoints for arm targets To: Zied Guermazi , coresight@lists.linaro.org, toolchain@lists.linaro.org, gdb@sourceware.org References: <8288e8d1-f5e7-5b69-5bac-370a37177097@trande.de> From: Luis Machado Message-ID: <05b117ac-8ce3-0ce7-bcf4-9d8596608a4a@linaro.org> Date: Wed, 4 Nov 2020 13:04:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8288e8d1-f5e7-5b69-5bac-370a37177097@trande.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_ASCII_DIVIDERS, NICE_REPLY_A, 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: Wed, 04 Nov 2020 16:04:26 -0000 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.