From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id AFF802119BAC5 for ; Wed, 26 Dec 2018 13:33:59 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4842F41A58; Wed, 26 Dec 2018 21:33:59 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-136.rdu2.redhat.com [10.10.121.136]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5BE55604CC; Wed, 26 Dec 2018 21:33:57 +0000 (UTC) To: Ard Biesheuvel , edk2-devel@lists.01.org References: <20181220173104.11481-1-ard.biesheuvel@linaro.org> <20181220173104.11481-5-ard.biesheuvel@linaro.org> From: Laszlo Ersek Message-ID: Date: Wed, 26 Dec 2018 22:33:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181220173104.11481-5-ard.biesheuvel@linaro.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 26 Dec 2018 21:33:59 +0000 (UTC) Subject: Re: [PATCH 4/4] ArmPkg/DefaultExceptionHandlerLib: use console if available X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 21:33:59 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 12/20/18 18:31, Ard Biesheuvel wrote: > Print the minimal 'exception occurred' message to the console instead > of straight 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 > --- > ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c | 16 +++++++++++++--- > ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c | 7 ++++++- > ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf | 1 + > 3 files changed, 20 insertions(+), 4 deletions(-) > > diff --git a/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c b/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c > index 1024bf48c63d..1aaf3c88f21e 100644 > --- a/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c > +++ b/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c > @@ -22,6 +22,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -159,14 +160,23 @@ DefaultExceptionHandler ( > INT32 Offset; > > if (mRecursiveException) { > - CharCount = AsciiSPrint (Buffer, sizeof (Buffer),"\nRecursive exception occurred while dumping the CPU state\n"); > - SerialPortWrite ((UINT8 *) Buffer, CharCount); > + STATIC CHAR8 CONST Message[] = "\nRecursive exception occurred while dumping the CPU state\n"; > + > + if (gST->ConOut != NULL) { > + AsciiPrint (Message); > + } else { > + SerialPortWrite ((UINT8 *)Message, AsciiStrLen (Message)); > + } > CpuDeadLoop (); > } > mRecursiveException = TRUE; > > CharCount = AsciiSPrint (Buffer,sizeof (Buffer),"\n\n%a Exception at 0x%016lx\n", gExceptionTypeString[ExceptionType], SystemContext.SystemContextAArch64->ELR); > - SerialPortWrite ((UINT8 *) Buffer, CharCount); > + if (gST->ConOut != NULL) { > + AsciiPrint (Buffer); > + } else { > + SerialPortWrite ((UINT8 *)Buffer, CharCount); > + } > > DEBUG_CODE_BEGIN (); > CHAR8 *Pdb, *PrevPdb; > diff --git a/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c b/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c > index 0b9da031b47d..9159b579da6f 100644 > --- a/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c > +++ b/ArmPkg/Library/DefaultExceptionHandlerLib/Arm/DefaultExceptionHandler.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > > #include > > @@ -194,7 +195,11 @@ DefaultExceptionHandler ( > > CharCount = AsciiSPrint (Buffer,sizeof (Buffer),"\n%a Exception PC at 0x%08x CPSR 0x%08x ", > gExceptionTypeString[ExceptionType], SystemContext.SystemContextArm->PC, SystemContext.SystemContextArm->CPSR); > - SerialPortWrite ((UINT8 *) Buffer, CharCount); > + if (gST->ConOut != NULL) { > + AsciiPrint (Buffer); > + } else { > + SerialPortWrite ((UINT8 *)Buffer, CharCount); > + } > > DEBUG_CODE_BEGIN (); > CHAR8 *Pdb; > diff --git a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf > index 7609f82d89a1..6bc48714c9dc 100644 > --- a/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf > +++ b/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf > @@ -42,6 +42,7 @@ > PeCoffGetEntryPointLib > ArmDisassemblerLib > SerialPortLib > + UefiBootServicesTableLib > > [Guids] > gEfiDebugImageInfoTableGuid > I feel that invoking such high level functionality from an exception handler is risky, but I do understand this is a last resort / best effort action, and if it *happens* to work on systems with no serial, then it's already a win. However, I'd suggest improving the robustness by preserving the serial write first, and then performing the (optional) console write in addition, second. I guess it can lead to the message appearing twice on serial (if the console is available, and it happens to be multiplexed to the serial port as well), but I think that's a better compromise than possibly losing the message altogether. I don't feel strongly about it either way, I just thought this worth raising. Thanks, Laszlo