public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Andrew Fish <afish@apple.com>, Daniil Egranov <daniil.egranov@arm.com>
Cc: "Carsey, Jaben" <jaben.carsey@intel.com>,
	edk2-devel-01 <edk2-devel@ml01.01.org>,
	Leif Lindholm <Leif.Lindholm@arm.com>,
	"Shah, Tapan (tapandshah@hpe.com)" <tapandshah@hpe.com>
Subject: Re: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform
Date: Wed, 5 Oct 2016 22:17:49 +0200	[thread overview]
Message-ID: <618fd786-24d4-653c-d6b8-cb774654c644@redhat.com> (raw)
In-Reply-To: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com>

On 10/05/16 21:48, Andrew Fish wrote:
> 
>> On Oct 5, 2016, at 12:24 PM, Daniil Egranov <daniil.egranov@arm.com> wrote:
>>
>> I have the same ASSERT issue on Juno platform even the EnglishDxe.inf is included to the platform build. If UefiShellLib has such dependency on the protocol then according to EDKII Module Writer's Guide you need to specify the dependency on protocol in the module .inf to ensure the drivers proper load sequence.
>>
>> 8.6 Dependency Expressions
>> A dependency expression specifies the protocols that the DXE driver requires to
>> execute. In EDK II, it is specified in the [Depex] section of INF file.
>>
> 
> The Dependency Expression is for DXE Drivers that are dispatched by the DXE Core. A UEFI Driver from an option ROM or an Application does not get dispatched by the dispatch and the Depex will not help. The Depex ends up being a section in the FV and it has nothing to do with the PE/COFF image of the an application or option ROM. 
> 
> IMHO the shell should try as hard as possible to function and should not ASSERT if some newer Protocol is missing.  

(Background: commit 583448b441650.)

In this specific case, the protocol dependency seems possible to eliminate:

- Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c
includes the CharToUpper() function, which is minimal -- could even be
copied or moved over -- and can translate the ASCII subset of UCS-2,

- once the ASCII characters of the input string have been translated to
upper case, the result could be searched for / compared against L"NULL"
using BaseLib.h APIs.

(Given that L"NULL" only contains characters from the ASCII subset, it
suffices to upper-case ASCII chars in the input string. No non-ASCII
character in the BMP can translate to ASCII N/U/L via upcasing, even
with the real collation protocol (I trust), and no other ASCII
characters than n/u/l will translate to N/U/L. This means that we won't
miss an instance of NULL because we didn't upcate it (because it was
non-ascii), and it also means we won't mistakenly match something
non-NULL as NULL.)

Just my two cents.

Laszlo


  reply	other threads:[~2016-10-05 20:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04 22:51 Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform Supreeth Venkatesh
2016-10-05 15:40 ` Carsey, Jaben
2016-10-05 16:02   ` Shah, Tapan
2016-10-05 19:24     ` Daniil Egranov
2016-10-05 19:46       ` Tim Lewis
2016-10-05 19:48       ` Andrew Fish
2016-10-05 20:17         ` Laszlo Ersek [this message]
2016-10-05 20:24           ` Shah, Tapan
2016-10-05 20:34             ` Carsey, Jaben
2016-10-05 20:39               ` Shah, Tapan
2016-10-05 20:44               ` Tim Lewis
2016-10-05 20:58                 ` Laszlo Ersek
2016-10-05 20:59                   ` Andrew Fish
2016-10-05 21:06                     ` Laszlo Ersek
2016-10-05 21:06                     ` Tim Lewis
2016-10-05 21:17                       ` Carsey, Jaben
2016-10-05 21:33                         ` Tim Lewis
2016-10-05 22:17                           ` Carsey, Jaben
2016-10-06  7:22                             ` Laszlo Ersek
2016-10-05 21:05                   ` Tim Lewis
2016-10-05 20:48             ` Laszlo Ersek
2016-10-05 20:53         ` Daniil Egranov
2016-10-05 21:04           ` Laszlo Ersek
2016-10-05 21:05           ` Andrew Fish
2016-10-05 21:15             ` Carsey, Jaben
2016-10-05 21:20               ` Andrew Fish
2016-10-05 21:25               ` Laszlo Ersek
2016-10-05 21:42               ` Daniil Egranov
2016-10-05 21:18             ` Laszlo Ersek
2016-10-05 21:34               ` Kinney, Michael D
2016-10-05 21:48                 ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=618fd786-24d4-653c-d6b8-cb774654c644@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox