From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nx230.node01.secure-mailgate.com (nx230.node01.secure-mailgate.com [89.22.108.230]) by sourceware.org (Postfix) with ESMTPS id AB83F386F00E for ; Mon, 2 Nov 2020 15:52:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AB83F386F00E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=trande.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zied.guermazi@trande.de Received: from host202.checkdomain.de ([185.137.168.148]) by node01.secure-mailgate.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1kZc7y-00HLC7-W4; Mon, 02 Nov 2020 16:52:20 +0100 X-SecureMailgate-Identity: zied.guermazi@trande.de;host202.checkdomain.de Received: from [192.168.178.21] (x4db94a72.dyn.telefonica.de [77.185.74.114]) (Authenticated sender: zied.guermazi@trande.de) by host202.checkdomain.de (Postfix) with ESMTPSA id 6970D2E55DA; Mon, 2 Nov 2020 16:52:12 +0100 (CET) Subject: Re: GDB: etm traces decoding and breakpoints for arm targets To: Mike Leach , linaro-toolchain@lists.linaro.org, Coresight ML Cc: markus.t.metzger@intel.com, luis.machado@linaro.org, gdb@sourceware.org References: <8288e8d1-f5e7-5b69-5bac-370a37177097@trande.de> From: Zied Guermazi Message-ID: Date: Mon, 2 Nov 2020 16:52:14 +0100 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: Content-Language: en-US X-PPP-Message-ID: <20201102155212.3733396.64668@host202.checkdomain.de> X-PPP-Vhost: trande.de X-Originating-IP: 185.137.168.148 X-SecureMailgate-Domain: host202.checkdomain.de X-SecureMailgate-Username: 185.137.168.148 Authentication-Results: secure-mailgate.com; auth=pass smtp.auth=185.137.168.148@host202.checkdomain.de X-SecureMailgate-Outgoing-Class: ham X-SecureMailgate-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0QBfAh7lyK8tB8mq1asnDr6pSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKyP9eGNFz9TW9u+Jt8z2T3KSZKa7laaLmORdqRXKwwQP3sU GJ2ooE6KXTxYpps8XkF4/qtTV5Y2YqW9ur9NLxL5s/SxKucavd8G8dqWyUaanMvG2IfngT4f8G5K DBO8etsfEyvYJB6tt9U7e44DfFCEcGBwEqvFskJleDemNHxH6r1pyQkjpFWqtP/gNvXJdBSRxBxS RBDMK60+V+HmA7TPfGhWAfoJ/8Ww9NkawL86ox1fWADySlN30KkX5qpAlQECRXxeC9lIp6R55qkF 7LzzWmuNA8WTybi1JN85FSnfKaZl5e9CnNR0t//S8nh6vX/q7dpdmYA25n9/VA/kFW0+L41cd/XA nxoMys6i8Aj5Y5myCtlKNfU+5VB9yzvTGUKdoog6HAd2t/eml19KJea5B00zgTKuyX14BpBV7EXX WbM5VcI9Z9iQLx1EhkIGnvf+rZCz88GCcFPvIEswICEp2WGMnItF5IurC2Rv2TRR0q6IKeqlAOpm 5XDq5f1EMUkI/ocfEccVEnhEQijS88dM//vtwKSj8Qbv7u4vEGUtpVH+HudMOYiiucJcUbi+1SpI iSAIMVqLLP87PrxLLBkexG5o9W4mrh1035LE160YWvDZ/9ky5X8+4m4gZ4/Q/B32LUC2EKcFH+yk n7aJaQbLR83CRbruZ25UsAs/h2Pk9Aswr0cL6lRAEDJHTf5jN3xZaHzuUu9r7mKgJFCBPxCe9N23 tNgDdEicQp9eamOcGk6ayhdwbXDpIBVlfNez3letI4g+l6rCWbY0MZcgnbHsdPEIkhwyn1gNIjLA MZECA3dbO4cvu+aFxPI2RebZ5Jwck+FdjHipZ4oMB1W1eX9ty35hlKFAbBAzFuL1JxbVjcaZpmjx pcF0txTCa2NdEtIyDwlE+jqd7oTWX787b10o5w6v920dMKwbz5xNOyNDSplFOKp6SGwsgE9xKoNN mM9HIwhS1wBuApLXaS536BdTA5d8QEMY9TcLEu9Jk0GUNTv+prrSKVuf6glK+7AsB5LIHahWPCkP RIMaeFBntelPEAkj3A+Ayf90lXAE1KL6y8kuUwcA0DVuzZHiJFwffG8+mQKTQkI8IFfL4UUFqn7T a8l84j4yYnhyduAtV+uhJ2NFOLpVp7NdmxP0DX099g+pzYqnxOTPqDcPUUXtB91ktwfcbKzS1jyd YoGqixfI8QfvOdKFRU7W7xm6A+5J2jQTrk9wwq6nH7z/b3gCyLA3njQ69KUF/5eqeLVxupMapQ== X-Report-Abuse-To: spam@node04.secure-mailgate.com X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, HTML_MESSAGE, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_KAM_HTML_FONT_INVALID autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 15:52:28 -0000 hi Thanks Mike for your support, it was very helpful. to put everything together, on arm, gdb inserts a sw breakpoint by patching the code with an undefined instruction ( see comments in  arm-tdep.c line7687) when a breakpoint is hit, an exception number 9 "Undefined Instruction exception" is raised and a branch packet with this info is generated in etm traces, the trap is get handled by the kernel and it sends the appropriate signal to gdb process. when the user continues the execution, gdb patches back the code and executes the instruction. this leads to the instruction traced twice with an exception in between, the same happens for next executed instruction here is the log of decoded packets [btrace] [ftrace] update insn: fun = main, file = ./function_call_history.c, level = 0, insn = [1; 2) cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE */<= first execution attempt that raises an undefined instruction exception/* trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400534 end addr   = 0x400536 instructions count = 1 last_i_type: OCSD_INSTR_OTHER last_i_subtype: OCSD_S_INSTR_NONE last instruction was executed last instruction size: 2 [btrace] [ftrace] update insn: fun = main, file = ./function_call_history.c, level = 0, insn = [1; 3) cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_EXCEPTION */<= the exception is traced/* trace_chan_id: 18 exception number: 9 */<= undefined instruction exception/* cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_TRACE_ON cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_PE_CONTEXT cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_INSTR_RANGE */<= execution of the original instruction/* trace_chan_id: 18 isa: CS_ETM_ISA_T32 start addr = 0x400534 end addr   = 0x400536 instructions count = 1 last_i_type: OCSD_INSTR_OTHER last_i_subtype: OCSD_S_INSTR_NONE last instruction was executed last instruction size: 2 as the code was changed during execution, it can not be reconstructed during traces decoding. in addition, and for tracing applications running on Linux, we are not interested in capturing raised exceptions, we can consider rolling back last instruction in ftraces. As this is not obvious, we can consider ignoring the repeated instruction as a workaround. for tracing bare metal software, we need to keep tracing exception, so we can have a flag for ignoring exceptions, and activate or dis-activate it according to the context. what do you think about it, shall I go for implementing it as described above? Kind Regards Zied Guermazi On 02.11.20 12:59, Mike Leach wrote: > 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 > >