ArmDisassemblerLib is used to pretty print the instruction that
triggered an unhandled exception, but it was never implemented for
AARCH64, and according to the existing file comment, Thumb2 support
(which is used predominantly when building EDK2 for 32-bit ARM due to
its smaller size) is incomplete.
The DEBUG diagnostics that are produced on an unhandled exception are
generally sufficient to dump the entire executable that triggered it,
and so this disassembly is of limited value, especially because it
doesn't work on AARCH64.
So let's start getting rid of it, by dropping references to it in code
and in the various .INF and .DSC files. Once out-of-tree platforms have
been allowed to catch up, we can remove the library implementation and
its class definition entirely.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The current DescribeExceptionSyndrome is taking ESR as 32bit value.
However, ESR should be a 64 bit value. This change updates the function
to intake a 64bit value.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
When building OvmfPkg in RELEASE mode in the XCODE5 toolchain, the
ASSERT_EFI_ERROR change prevents this error:
.../MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:141:15:
error: variable 'Status' set but not used [-Werror,-Wunused-but-set-variable]
EFI_STATUS Status;
^
which is currently stopping the build.
When building in RELEASE mode in the CLANGPDB toolchain,the DEBUG macro
change prevents this error:
.../edk2/OvmfPkg/VirtioSerialDxe/VirtioSerial.c:28:22: error:
variable 'EventNames' is not needed and will not be
emitted [-Werror,-Wunneeded-internal-declaration]
STATIC CONST CHAR8 *EventNames[] = {
^
which is currently stopping the build.
CLANGDWARF produces the same error as CLANGPDB above, if
-Wno-unneeded-internal-declaration is removed from its build flags.
With the null DEBUG macro change, this warning suppression
can be removed from CLANGDWARF, which is considered a benefit
as it has the potential to catch real coding errors. This is
done in a subsequent commit.
This commit has the desirable side effect that we no longer require
(and cannot use) explicit `#ifndef MDEPKG_NDEBUG` around items only
used in DEBUG macros. This requires the ArmPkg change made here to
be in the same commit as the MdePkg changes.
Note: In common with existing macros in EDK II, including the pre-existing
and unchanged DEBUG/NOOPT versions of the macros which are modified here,
we use the standard approach of adding `do { ... } while (FALSE)` wrapping
to ensure that the macros behave correctly with surrounding code
(e.g. require a following ';' and do not combine in unexpected ways with
nearby conditionals).
Continuous-integration-options: PatchCheck.ignore-multi-package
Co-authored-by: Mikhail Krichanov <krichanov@ispras.ru>
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
If gST->ConOut is available when Arm's DefaultExceptionHandler is
running, AsciiPrint will get called to attempt to print to ConOut, in
addition to the serial output.
AsciiPrint calls AsciiInternalPrint in UefiLibPrint.c which in turn
calls AllocatePool to allocate a buffer to convert the Ascii input
string to a Unicode string to pass to ConOut->OutputString.
Per the comment on DefaultExceptionHandler, we should not be allocating
memory in the exception handler, as this can cause the exception handler
to fail if we had a memory exception or the system state is such that we
cannot allocate memory.
It has been observed on ArmVirtQemu that exceptions generated in the
memory handling code will fail to output the stack dump and CPU state
that is critical to debugging because the AllocatePool will fail.
This patch fixes the Arm and AARCH64 DefaultExceptionHandlers to not
allocate memory when ConOut is available and instead use stack memory to
convert the Ascii string needed for SerialPortWrite to the Unicode
string needed for ConOut->OutputString. Correspondingly, ArmVirtQemu can
now output the stack dump and CPU state when hitting an exception in
memory code.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the ArmPkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Andrew Fish <afish@apple.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Print the minimal 'exception occurred' message to the console as well
as to the serial port if the console is available. This makes such
messages visible on systems where the console is graphical and the
serial is not connected.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Currently, we only attempt to walk the call stack and print a backtrace
if the program counter refers to a location covered by a PE/COFF image.
However, regardless of the value of PC, the frame pointer may still have
a meaningful value, and so we can still produce the remainder of the
backtrace.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
As reported by Vishal, the new backtrace output would be more useful if
it did not contain the full absolute path of each module in the list.
So strip off everything up to the last forward slash or backslash in the
string.
Example output:
IRQ Exception at 0x000000005EF110E0
DxeCore.dll loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EF121F0) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EF1289C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFB6B4) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFAA44) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFB450) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF938C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF8D04) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEFA8E8) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF3C14) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEF3E48) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EF0C838) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEEF70C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEEE93C) loaded at 0x000000005EEED000
called from DxeCore.dll (0x000000005EEEE024) loaded at 0x000000005EEED000
Suggested-by: "Oliyil Kunnil, Vishal" <vishalo@qti.qualcomm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
When dumping the CPU state after an unhandled fault, walk the stack
frames and decode the return addresses so we can show a minimal
backtrace. Unfortunately, we do not have sufficient information to
show the function names, but at least we can see the modules and the
return addresses inside the modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>
Putting DEBUG () code after an ASSERT (FALSE) statement is not very
useful, since the code will be unreachable on DEBUG builds and compiled
out on RELEASE builds. So move the ASSERT () statement after it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
This adds a partial stack dump (256 bytes at either side of the stack
pointer) to the CPU state dumping routine that is invoked when taking an
unexpected exception. Since dereferencing the stack pointer may itself
fault, ensure that we don't enter the dumping routine recursively.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
The default exception handler, which is essentially the one that is invoked
for unexpected exceptions, ends with an ASSERT (FALSE), to ensure that
execution halts after dumping the CPU state. However, ASSERTs are compiled
out in RELEASE builds, and since we simply return to wherever the ELR is
pointing, we will not make any progress in case of synchronous aborts, and
the same exception will be taken again immediately, resulting in the string
'Exception at 0x....' to be printed over and over again.
So use an explicit deadloop instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Modify the DefaultExceptionHandler (uefi-variant) so it can be used by
DxeCore (via CpuExceptionHandlerLib) where the debug info table is not
yet published at library constructor time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eugene@hp.com>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
