From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c0c::22e; helo=mail-wr0-x22e.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 82BE6223C1766 for ; Tue, 20 Feb 2018 06:10:47 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id l43so14841840wrc.2 for ; Tue, 20 Feb 2018 06:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YVoHxYyoDvkZlm8bAOmSZWi8YHm7ef4fr0Mk8qfkM6I=; b=N8v2L1s9kD3TsbEDeNm0iVACTkGq7od077ELYGk7arQWZ/F8rG7p5kfI5WY0V5/rMe hnv6JowHU+LIG5cLM4KGxRa10QJaJwSgiKJWgrsuQFKJM+1BH8YvpxpVs9BKGurBpayo muJhuR/PzfZtAsNh37Abk1iRUMQkB7KwCZPkE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YVoHxYyoDvkZlm8bAOmSZWi8YHm7ef4fr0Mk8qfkM6I=; b=dhVsXzQuXgU5C88u5/RZzj4DzMp2nL7jyVPXONts2AxSGhSQsMkL+CiPrx+j1x8kCE t6+sLLMfUWnco2t+T193JTYnMGWGr1ni58JWoD+Qlw3vpsjuEtY+9Xpgkq4P+ybKGuYk CY1+Khd3A+QJx+3jesw92WCdTgU+skPx3OClIm3yhIf6Nmgv4g+Gp/1zaGb3W4Eo8RD1 Iqq+X3A4EkV81sfUG/ZBk9z3CZppu+t7rezrqO42ZlyPM2eXpKnflBEsIWm1LhN/Lyvn Sa61yg5AZ90Xm/VLxlbX3ZKvfaP9rLloW2ZDgShvM+EdDAZnP7Opv+/bpPJihvEivp8G Yw7Q== X-Gm-Message-State: APf1xPBDjLNZvKsQg+LPzXs88DLL86anRO/DeSA2wYhgoS8uhji9WSb2 6QrO7agGl9eNWOJv6d3V9jc6lg== X-Google-Smtp-Source: AH8x227GKGlfULeeMLEEJft+xdDhi2qNBUmNZCN8qRttFthPg6Wqf7f2JicHAMZathAyW6xCmx6PJQ== X-Received: by 10.223.164.153 with SMTP id g25mr10096691wrb.79.1519136204655; Tue, 20 Feb 2018 06:16:44 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id e66sm16722783wmc.39.2018.02.20.06.16.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Feb 2018 06:16:43 -0800 (PST) Date: Tue, 20 Feb 2018 14:16:41 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: edk2-devel@lists.01.org, ruiyu.ni@intel.com, michael.d.kinney@intel.com, liming.gao@intel.com, lersek@redhat.com, star.zeng@intel.com, afish@apple.com Message-ID: <20180220141641.p47czk4yb74xutyu@bivouac.eciton.net> References: <20180220110524.9050-1-ard.biesheuvel@linaro.org> <20180220110524.9050-2-ard.biesheuvel@linaro.org> MIME-Version: 1.0 In-Reply-To: <20180220110524.9050-2-ard.biesheuvel@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH 1/3] MdePkg: introduce DxeRuntimeDebugLibSerialPort X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 14:10:49 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 20, 2018 at 11:05:22AM +0000, Ard Biesheuvel wrote: > +/** > + Prints an assert message containing a filename, line number, and description. > + This may be followed by a breakpoint or a dead loop. > + > + Print a message of the form "ASSERT (): \n" > + to the debug output device. If DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED bit > + of PcdDebugProperyMask is set then CpuBreakpoint() is called. Otherwise, if > + DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED bit of PcdDebugProperyMask is set then > + CpuDeadLoop() is called. If neither of these bits are set, then this function > + returns immediately after the message is printed to the debug output device. > + DebugAssert() must actively prevent recursion. If DebugAssert() is called > + while processing another DebugAssert(), then DebugAssert() must return > + immediately. > + > + If FileName is NULL, then a string of "(NULL) Filename" is printed. > + If Description is NULL, then a string of "(NULL) Description" is > + printed. > + > + @param FileName The pointer to the name of the source file that generated > + the assert condition. > + @param LineNumber The line number in the source file that generated the > + assert condition > + @param Description The pointer to the description of the assert condition. > + > +**/ > +VOID > +EFIAPI > +DebugAssert ( > + IN CONST CHAR8 *FileName, > + IN UINTN LineNumber, > + IN CONST CHAR8 *Description > + ) > +{ > + CHAR8 Buffer[MAX_DEBUG_MESSAGE_LENGTH]; > + > + if (!mEfiAtRuntime) { > + // > + // Generate the ASSERT() message in Ascii format > + // > + AsciiSPrint (Buffer, sizeof (Buffer), "ASSERT [%a] %a(%d): %a\n", > + gEfiCallerBaseName, FileName, LineNumber, Description); > + > + // > + // Send the print string to the Console Output device > + // > + SerialPortWrite ((UINT8 *)Buffer, AsciiStrLen (Buffer)); > + } > + > + // > + // Generate a Breakpoint, DeadLoop, or NOP based on PCD settings > + // > + if ((FixedPcdGet8 (PcdDebugPropertyMask) & > + DEBUG_PROPERTY_ASSERT_BREAKPOINT_ENABLED) != 0) { > + CpuBreakpoint (); > + } else if ((FixedPcdGet8 (PcdDebugPropertyMask) & > + DEBUG_PROPERTY_ASSERT_DEADLOOP_ENABLED) != 0) { > + CpuDeadLoop (); > + } Hmm ... I know this does not fundamentally change the behaviour of the existing implementation, but if we're looking to improve runtime behaviour, we've just gone from generating a runtime fault to silently freezing (if BREAKPOINT_ENABLED or DEADLOOP_ENABLED). What do breakpoint/deadloop mean in a runtime context anyway - do we not need to halt _all_ running cores? I don't see an obvious "right way" solution here, and this only affects DEBUG builds. Possible ways of handling this that I can think of include: - Don't respect BREAKPOINT/DEADLOOP if at runtime. - Respect BREAKPOINT/DEADLOOP and disable all cores. - Take ownership back of the system and re-enable 1:1 mapping so messages can be printed. / Leif