From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by sourceware.org (Postfix) with ESMTPS id 6640B3854810 for ; Tue, 3 Nov 2020 11:02:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6640B3854810 Received: by mail-yb1-xb34.google.com with SMTP id h196so14476824ybg.4 for ; Tue, 03 Nov 2020 03:02:35 -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:content-transfer-encoding; bh=G2wQyb6NUjStPbPhxKhQnWX2HQR7PJjC11YtBGPfCQs=; b=ZOU7nzYSq7+4vTAqUq9hZxO4EVtdoXMsa0HBR/Dz7BuPJr4vpIaP6Jv5YtXXIGIi6I A0+lLbJAx0H0dx8G+VZJcziCLixL/X8WJqMHATKQW3eQcO/9A8xSeCAoJyODju7fElAw TVoDWDIQmpxZdjaPN0Q4ClJpWa2+H8COqmvhhPhFOFocTC7Vvvt+s+9t9UpQMTDwa/85 h2KhtvPy2CBM7wDtQDPdf/Sbc7YYDRp0szLtA/F920mJrowCq6f1HsUJla+Q4AABXT1j 0aQd3/Khfj/RoxwCSo6pRELgLc2rGucP8usMGjBhKRzAevPQ9wgZJ+SMg39xA2PnJ0Ov x1UA== X-Gm-Message-State: AOAM5313Lmyg+t/3DUaC0sBfNf9EeB3BIUgRQfz5YWtvdgr6og3nW2Z5 939d8W0Vs/Kl/GgGu7nKPYMzB5IjCfJbg7xq0NmHQw== X-Google-Smtp-Source: ABdhPJwpyCN9YWhO7pZo+OkVgwT+9+2tGawX5leC17GSogk0zhC1+OHBiaevsYEjc6eEaoB9vZQtTcF2y6qNtmmzFfc= X-Received: by 2002:a25:f8a:: with SMTP id 132mr427482ybp.440.1604401354472; Tue, 03 Nov 2020 03:02:34 -0800 (PST) MIME-Version: 1.0 References: <8288e8d1-f5e7-5b69-5bac-370a37177097@trande.de> In-Reply-To: From: Mike Leach Date: Tue, 3 Nov 2020 11:02:23 +0000 Message-ID: Subject: Re: GDB: etm traces decoding and breakpoints for arm targets To: Zied Guermazi Cc: linaro-toolchain@lists.linaro.org, Coresight ML , markus.t.metzger@intel.com, luis.machado@linaro.org, gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 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: Tue, 03 Nov 2020 11:02:37 -0000 Hi Zied, On Mon, 2 Nov 2020 at 15:52, Zied Guermazi wrote: > > hi > > Thanks Mike for your support, it was very helpful. > > to put everything together, on arm, gdb inserts a sw breakpoint by patchi= ng the code with an undefined instruction ( see comments in arm-tdep.c lin= e7687) when a breakpoint is hit, an exception number 9 "Undefined Instructi= on 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 appropri= ate signal to gdb process. > Looks like that code was designed for very early architectures. I wonder if it should not use the architected BKPT instruction when available (arch v5T onwards I think). > when the user continues the execution, gdb patches back the code and exec= utes the instruction. this leads to the instruction traced twice with an ex= ception in between, the same happens for next executed instruction > > here is the log of decoded packets > > [btrace] [ftrace] update insn: fun =3D main, file =3D ./function_call_his= tory.c, level =3D 0, insn =3D [1; 2) > cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_= INSTR_RANGE <=3D first execution attempt that raises an undefined instructi= on exception > trace_chan_id: 18 > isa: CS_ETM_ISA_T32 > start addr =3D 0x400534 > end addr =3D 0x400536 > instructions count =3D 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 =3D main, file =3D ./function_call_his= tory.c, level =3D 0, insn =3D [1; 3) > cs_etm_decoder_trace_element_callback: elem->elem_type OCSD_GEN_TRC_ELEM_= EXCEPTION <=3D the exception is traced > trace_chan_id: 18 > exception number: 9 <=3D 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 <=3D execution of the original instruction > trace_chan_id: 18 > isa: CS_ETM_ISA_T32 > start addr =3D 0x400534 > end addr =3D 0x400536 > instructions count =3D 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 dur= ing traces decoding. > > in addition, and for tracing applications running on Linux, we are not in= terested in capturing raised exceptions, we can consider rolling back last = instruction in ftraces. As this is not obvious, we can consider ignoring th= e 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 a= ccording to the context. > > what do you think about it, shall I go for implementing it as described a= bove? > > I assume that in this scenario, trace collection is ongoing over the BKPT hit / restart sequence and is decoded at some point later. Otherwise spotting the breakpoint would be easy. I cannot think of many circumstances where an instruction would be executed - or appear to be executed in the trace twice in succession* - other than being restarted after an exception. This debug case is one of those occasions - I would check that there are not other exceptions that might mimic this. Other than that it would appear that the execute / exception / execute again pattern can be used to spot a break and the 1st execute could be dropped since this was the breakpoint. If it was set on a conditional then you are interested in the actual trace result which could be either executed or not. Regards Mike * branch to self might appear like this, as would setting the trace address filters to a include just single instruction - but there would be no intervening exceptions in these cases. > 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 wro= te: > > 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 =3D 0x400552 > end addr =3D 0x400554 > instructions count =3D 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 =3D 0x400552 > end addr =3D 0x400554 > instructions count =3D 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 =3D 0x400554 > end addr =3D 0x400558 > instructions count =3D 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 =3D 0x400554 > end addr =3D 0x400558 > instructions count =3D 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 > > --=20 Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK