From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp00.avonet.cz (smtp00.avonet.cz [217.112.162.55]) by sourceware.org (Postfix) with ESMTP id 5D06038582A1 for ; Sun, 16 Oct 2022 13:59:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5D06038582A1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=fbl.cz Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=fbl.cz Received: from ktus.lan (217-115-245-101.cust.avonet.cz [217.115.245.101]) by smtp00.avonet.cz (Postfix) with ESMTP id 4Mr1vF2Hfcz1xq6 for ; Sun, 16 Oct 2022 15:59:05 +0200 (CEST) Received: by ktus.lan (Postfix, from userid 209) id 284B030B978; Sun, 16 Oct 2022 15:59:05 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, SPF_FAIL, SPF_HELO_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 Received: from [192.168.33.9] (217-115-245-101.cust.avonet.cz [217.115.245.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vanekt) by ktus.lan (Postfix) with ESMTPSA id EF1E130B976 for ; Sun, 16 Oct 2022 15:59:03 +0200 (CEST) Message-ID: Date: Sun, 16 Oct 2022 15:59:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 From: Tomas Vanek Subject: [PATCH] gdb/arm: Terminate frame unwinding in M-profile lockup state To: gdb-patches@sourceware.org Content-Language: en-US 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-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2022 13:59:10 -0000 Torbjorn, thanks for the fast reply. On 2022-10-16 10:13, Torbjorn SVENSSON wrote: > >/  #0  0xeffffffe in ?? () />/  #1  0x0c000a9c in HardFault_Handler () />/      at />/C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99 > />/  #2  0x2002ffd8 in ?? () />/  Backtrace stopped: previous frame identical to this frame (corrupt />/stack?) />/  (gdb) />/---------------- />/The frame #1 is at correct PC taken from LR, #2 is a total nonsense. / > I think your assumption here is wrong as 0xeffffffe is a valid value for > Cortex-M33 with TrustZone (FNC_RETURN with S=0). See more on the comment > below. 'B3.17 Function returns from Non-secure state' states: The FNC_RETURN value is: ... the original is a binary value in a table, hard to convert to plain text ... so if I convert correctly 0xfefffffe or 0xfeffffff depending on S bit. Starts with 0xfe not 0xef as the lockup magic! > Reading B3.33 (revision B.m) in the ARMv8-M documentation about lockup > state, it's written that DHCSR.S_LOCKUP=1 AND PC=0xeffffffe. My > interpretations that the PC value alone is not enough. Hmm, how would we read DHCSR then? IMO the PC value is enough. Tomas From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp00.avonet.cz (smtp00.avonet.cz [217.112.162.55]) by sourceware.org (Postfix) with ESMTP id 5D06038582A1 for ; Sun, 16 Oct 2022 13:59:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5D06038582A1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=fbl.cz Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=fbl.cz Received: from ktus.lan (217-115-245-101.cust.avonet.cz [217.115.245.101]) by smtp00.avonet.cz (Postfix) with ESMTP id 4Mr1vF2Hfcz1xq6 for ; Sun, 16 Oct 2022 15:59:05 +0200 (CEST) Received: by ktus.lan (Postfix, from userid 209) id 284B030B978; Sun, 16 Oct 2022 15:59:05 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,BODY_8BITS,HTML_MESSAGE,KAM_DMARC_STATUS,SPF_FAIL,SPF_HELO_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 Received: from [192.168.33.9] (217-115-245-101.cust.avonet.cz [217.115.245.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vanekt) by ktus.lan (Postfix) with ESMTPSA id EF1E130B976 for ; Sun, 16 Oct 2022 15:59:03 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------F886BT9qX8zNsefbQusTEtAD" Message-ID: Date: Sun, 16 Oct 2022 15:59:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 From: Tomas Vanek Subject: [PATCH] gdb/arm: Terminate frame unwinding in M-profile lockup state To: gdb-patches@sourceware.org Content-Language: en-US List-Id: Message-ID: <20221016135904.AUGl2IciwNZveigSyB3IxfZjCCA1Z_EwwQQhCWFA3Os@z> This is a multi-part message in MIME format. --------------F886BT9qX8zNsefbQusTEtAD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Torbjorn, thanks for the fast reply. On 2022-10-16 10:13, Torbjorn SVENSSON wrote: > >/  #0  0xeffffffe in ?? () />/  #1  0x0c000a9c in HardFault_Handler () />/      at />/C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99 > />/  #2  0x2002ffd8 in ?? () />/  Backtrace stopped: previous frame identical to this frame (corrupt />/stack?) />/  (gdb) />/---------------- />/The frame #1 is at correct PC taken from LR, #2 is a total nonsense. / > I think your assumption here is wrong as 0xeffffffe is a valid value for > Cortex-M33 with TrustZone (FNC_RETURN with S=0). See more on the comment > below. 'B3.17 Function returns from Non-secure state' states: The FNC_RETURN value is: ... the original is a binary value in a table, hard to convert to plain text ... so if I convert correctly 0xfefffffe or 0xfeffffff depending on S bit. Starts with 0xfe not 0xef as the lockup magic! > Reading B3.33 (revision B.m) in the ARMv8-M documentation about lockup > state, it's written that DHCSR.S_LOCKUP=1 AND PC=0xeffffffe. My > interpretations that the PC value alone is not enough. Hmm, how would we read DHCSR then? IMO the PC value is enough. Tomas --------------F886BT9qX8zNsefbQusTEtAD--