From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id D691EAC12D1 for ; Wed, 30 Aug 2023 13:00:39 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=W4Mt1VryBhyjNKBalkVBcpHklKUbjbGrAT2vsc44unM=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1693400438; v=1; b=v6/bQJ//2awkeTP5IzxlBzl418IDl/OXfQBDuRCozwiPVZEL8JfGULOyaoT0gOG9h8cYcySs AUJJZpeoUAU3q9rKmvqvROX/ASmuI5y2xaNSSyikPOHh/SFA8bz5Cvf8OHIR8VnBMmQ4SaW1a0c fixwAuOadvQPWJ8mFXCf4GNA= X-Received: by 127.0.0.2 with SMTP id fdZGYY7687511xPIqzMEcsGN; Wed, 30 Aug 2023 06:00:38 -0700 X-Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.13252.1693400437829622533 for ; Wed, 30 Aug 2023 06:00:38 -0700 X-Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 60B5860FEB for ; Wed, 30 Aug 2023 13:00:37 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB97EC433C9 for ; Wed, 30 Aug 2023 13:00:36 +0000 (UTC) X-Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-50091b91a83so8614206e87.3 for ; Wed, 30 Aug 2023 06:00:36 -0700 (PDT) X-Gm-Message-State: edauNNdjQtbejXEydo8Ie70Ix7686176AA= X-Google-Smtp-Source: AGHT+IGi90y8yZHHrOo6HapcaHx+5j13xuxJS18ofuAxOfqhKDsTCCmZxrTepoDRumBuGwuhORElFQpoaeuNwU7fpag= X-Received: by 2002:ac2:44a8:0:b0:500:9a67:d40e with SMTP id c8-20020ac244a8000000b005009a67d40emr1425253lfm.60.1693400434697; Wed, 30 Aug 2023 06:00:34 -0700 (PDT) MIME-Version: 1.0 References: <20230829132921.123407-1-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 30 Aug 2023 15:00:23 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/1] ArmPkg/ExceptionSupport: Support backtrace through an exception To: Laszlo Ersek Cc: devel@edk2.groups.io, quic_llindhol@quicinc.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b="v6/bQJ//"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Tue, 29 Aug 2023 at 16:37, Laszlo Ersek wrote: > > On 8/29/23 15:29, Ard Biesheuvel wrote: > > Laszlo reports that the efi_gdb.py script fails to produce a full > > backtrace when attaching it to an ARM firmware build that has halted on > > an unhandled exception. > > > > The reason is that the asm code that processes the exception was not > > implemented with this in mind, and therefore lacks any handling of it. > > > > So let's add this: create a dummy frame record suitable for chasing the > > frame pointer, and add the CFI metadata to describe where the return > > value can be found on the stack. > > > > When using a GCC5 build, this produces a stack trace such as > > > > (gdb) bt > > #0 0x000000007fd4537c in CpuDeadLoop () at /home/ardb/build/edk2/MdePkg/Library/BaseLib/CpuDeadLoop.c:30 > > #1 0x000000007fd454f8 in DebugAssert ( > > FileName=FileName@entry=0x7fd4a8a8 "/home/ardb/build/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c", > > LineNumber=LineNumber@entry=343, Description=Description@entry=0x7fd4a896 "((BOOLEAN)(0==1))") > > at /home/ardb/build/edk2/MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c:235 > > #2 0x000000007fd479ec in DefaultExceptionHandler (ExceptionType=, SystemContext=...) > > at /home/ardb/build/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c:343 > > #3 0x000000007fd48eb8 in ExceptionHandlersEnd () > > #4 0x000000007fcde944 in QemuLoadKernelImage (ImageHandle=) at /home/ardb/build/edk2/OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.c:201 > > #5 TryRunningQemuKernel () at /home/ardb/build/edk2/ArmVirtPkg/Library/PlatformBootManagerLib/QemuKernel.c:46 > > #6 PlatformBootManagerAfterConsole () at /home/ardb/build/edk2/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c:1139 > > #7 BdsEntry (This=) at /home/ardb/build/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:931 > > #8 0x000000007ffd0018 in ?? () > > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > > > when QemuLoadKernelImage() has been tweaked to trigger an exception, as > > is shown by GDB when walking the call stack: > > > > | 0x7fcde938 b.ne 0x7fcdf134 // b.any > > | 0x7fcde93c mov x0, #0x40 // #64 > > | 0x7fcde940 bl 0x7fcd7aec > > | > 0x7fcde944 brk #0x4d2 > > | 0x7fcde948 bl 0x7fce4354 > > | 0x7fcde94c tbz x0, #63, 0x7fcde954 > > | 0x7fcde950 bl 0x7fcd844c > > | 0x7fcde954 bl 0x7fcd990c > > > Unfortunately, CLANGDWARF does not seem entirely happy with this > > arrangement: it identifies the call frame where the exception > > originated, but does not show any frames above that. (This could be > > related to the fact that the exception code uses a separate exception > > stack for handling synchronous exceptions) > > First of all, thanks for writing this patch so incredibly quickly. :) > My pleasure. > Second, something must be off with my gdb. > > Before your patch, I kept experimenting with manually resetting FP, SP, > and LR to the values printed in the register dump, using gdb "set" > commands. Strangely, that did result in complete pre-exception stack > traces, but *only sometimes*. Most of the time gdb complains about > "corrupted stack". And I just can't figure out what distinguishes the > broken from the functional "bt" commands -- I did walk the allegedly > corrupt stack manually, and there is nothing corrupt in the FP and LR > parts of the stack frames. They all chain nicely and point to valid > instructions, respectively. I don't know what it is that gdb doesn't like. > I suspect that gdb is filled with heuristics and tweaks, and uses a combination of the frame records, the actual value of LR and the unwind data to figure out what the call stack looks like. > Third, when I test your patch, I seem to experience precisely what you > describe under CLANGDWARF -- it shows the faulting frame (the frame just > before the exception), but nothing before it! And I'm not building with > clang :( > Shame. Unfortunately, I don't have a lot of time to spend on this right now, but it is something I have been wanting to fix forever so hopefully I'll get back to it at some point. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#108144): https://edk2.groups.io/g/devel/message/108144 Mute This Topic: https://groups.io/mt/101030910/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-