From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7B5C83858413; Sun, 16 Oct 2022 12:24:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7B5C83858413 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1665923098; bh=gSSTQIeM+XwyaEM6lQ+yoc89CaSb8ibulVhchQ4JSEA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mc1K9te+AMjroiYPALHHy0Yivwwzre5w8hgrgyIO6ZNv4ccsdqlEe50qqKjfJLW+a i/v/5mq4PNcbDBMK0KbxbtkcDWYYCFuyrjeOyZLUN/4hfA6Z0VrzrmHGy91b0oHRoj MvSGelHH0agRtNwh9tUPfvT9R2dI7tbByj5ZuMFE= From: "tomas.vanek at fbl dot cz" To: gdb-prs@sourceware.org Subject: [Bug gdb/28549] ARM/Cortex-M: improper stack unwinding when the target is in lockup state Date: Sun, 16 Oct 2022 12:24:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 9.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tomas.vanek at fbl dot cz X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: luis.machado at arm dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28549 --- Comment #50 from tomas.vanek at fbl dot cz --- I finally submitted https://sourceware.org/pipermail/gdb-patches/2022-October/192716.html (In reply to Torbj=C3=B6rn SVENSSON from comment #49) >=20 > Right now, I'm more concerned about the endless(?) loop when the target is > in lockup state. Could it be explained by unwinding with wrong SP value because the size of the next outer frame cannot be determined because of unknown pre-lockup = PC? > > 'Show frame unwinder name in signal name' gives user little bit better = info > > than - it might be mergeable (I didn't check, w= ill > > do). >=20 > I think this patch could be an improvement, but not as important as the > previous one. Lets focus on getting the other one in first, okay? Because you doesn't seem to be happy with 'Show frame unwinder name in signal name'... > I just landed a patch that shows how you can use the=20 > frame_unwind_stop_reason hook to stop the unwinding. I think the same log= ic > could be used in your patch too. ... and your patch made much easier to stop unwinding without misleading messages, I simplified the change. Dedicated lockup unwinder is dropped, I added the equal functionality to the exception unwinder. TBH Personally I would prefer 3 dedicated unwinders: exception (EXC_RETURN), FNC_RETURN and lockup. I think that performance penalty would be negligible as the sniffers are simple and fast and the code would be cleaner. However = I'm not so familiar with gdb code so I respect your preference. BTW Thanks for the pointer to > Regarding the assurance, please see Pedro's reply to the very same questi= on > here: https://sourceware.org/pipermail/gdb-patches/2022-October/192655.ht= ml and submitting your '[PATCH v4] gdb/arm: Stop unwinding on error, but do not assert' and '[PATCH] gdb/arm: Don't rely on loop detection to stop unwind' They really make a difference. But there is a small drawback: as the warning messages are printed out in t= ime of building cache, they appear just once and if user e.g. repeats 'backtrac= e' command he gets no more messages. > > I wonder why arm_m_addr_is_magic() decoding differs so much in branches > > without and with the security extension. The former decodes just the us= ed > > special addresses, the latter whole pages with lot of 'undefined behavi= our' > > codes. >=20 > On > https://developer.arm.com/documentation/100701/0200/The-EXC-RETURN-regist= er, > it's written as that 0xffxxxxxx is an EXC_RETURN pattern, even if there a= re > combinations within that that is illegal. Hmm, this document really looks like the devices without sec ext have just 3 listed EXC_RETURNs. 'Arm=C2=AEv8-M Architecture Reference Manual', D1.2.95 'EXC_RETURN, Exception Return Payload' makes clear that the payload format = and bits assignment are same for both with and without sec ext, just some bits = are reserved in the case 'without sec'. So IMO detecting EXC_RETURN on a device with security extension should treat reserved bits same way as doing so on dev w/o sec, not to do the quite opposite. And one more suspicious point: ARMv8-M RM describes the FType bit 4 as it does not depend on sec ext. Correct me if I'm wrong it would mean that ARMv8-M device with FP and without security used also 0xFFFFFFA0, 0xFFFFFFA8 and 0xFFFFFFAC EXC_RETURNs. I don't have such device neither I'm not aware of any, it even does not exist at all. BTW it's quite easy to trigger the internal error at the end of arm_m_exception_cache(). Just set PC register to any of magic codes (I admit that doing so has little sense except showing another reason to ch= eck the reserved bits): On STM32L5 ARMv8-M with sec ext: (gdb) set $pc=3D0xff000000 ../../gdb/arm-tdep.c:3684: internal-error: While unwinding an exception fra= me, found unexpected Link Register value 0c0002cb. This should not happen and maybe caused by corrupt data or a bug in GDB. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x8119852 gdb_internal_backtrace_1 ../../gdb/bt-utils.c:122 0x8119852 _Z22gdb_internal_backtracev ../../gdb/bt-utils.c:168 0x843a40c internal_vproblem ../../gdb/utils.c:396 0x843a79e _Z15internal_verrorPKciS0_Pc ../../gdb/utils.c:476 0x8528326 _Z14internal_errorPKciS0_z ../../gdbsupport/errors.cc:58 0x80cf181 arm_m_exception_cache ../../gdb/arm-tdep.c:3689 0x80cff77 arm_m_exception_this_id ../../gdb/arm-tdep.c:3703 0x8257bbe compute_frame_id ../../gdb/frame.c:594 0x8257e49 _Z12get_frame_id14frame_info_ptr ../../gdb/frame.c:637 0x825b185 _Z16frame_find_by_id8frame_id ../../gdb/frame.c:906 0x8447bbf _Z12value_assignP5valueS0_ ../../gdb/valops.c:1304 0x8226a46 _ZN10expression8evaluateEP4type6noside ../../gdb/eval.c:101 0x8226e8e _Z19evaluate_expressionP10expressionP4type ../../gdb/eval.c:115 0x8328a4e set_command ../../gdb/printcmd.c:1519 0x814b1aa _Z8cmd_funcP16cmd_list_elementPKci ../../gdb/cli/cli-decode.c:2543 0x84001bb _Z15execute_commandPKci ../../gdb/top.c:692 0x822dff4 _Z15command_handlerPKc ../../gdb/event-top.c:616 0x822e366 _Z20command_line_handlerOSt10unique_ptrIcN3gdb13xfree_deleterIcEEE ../../gdb/event-top.c:860 On Kinetis K22, Cortex-M4 FP: (gdb) set $pc=3D0xFFFFFFBC the same error follows... --=20 You are receiving this mail because: You are on the CC list for the bug.=