From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe44::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5EFA71A1EE1 for ; Wed, 5 Oct 2016 13:24:45 -0700 (PDT) Received: from CS1PR84MB0229.NAMPRD84.PROD.OUTLOOK.COM (10.162.190.151) by CS1PR84MB0229.NAMPRD84.PROD.OUTLOOK.COM (10.162.190.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 20:24:43 +0000 Received: from CS1PR84MB0229.NAMPRD84.PROD.OUTLOOK.COM ([10.162.190.151]) by CS1PR84MB0229.NAMPRD84.PROD.OUTLOOK.COM ([10.162.190.151]) with mapi id 15.01.0649.024; Wed, 5 Oct 2016 20:24:43 +0000 From: "Shah, Tapan" To: Laszlo Ersek , Andrew Fish , "Daniil Egranov" CC: "Carsey, Jaben" , edk2-devel-01 , Leif Lindholm Thread-Topic: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform Thread-Index: AdIekL1EjMpAqwOYRWKk8YKyvfLMLgAjbAlwAACkBtAAB0V1AAAA2Y8AAAEEUoAAACH1QA== Date: Wed, 5 Oct 2016 20:24:42 +0000 Message-ID: References: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com> <618fd786-24d4-653c-d6b8-cb774654c644@redhat.com> In-Reply-To: <618fd786-24d4-653c-d6b8-cb774654c644@redhat.com> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tapandshah@hpe.com; x-originating-ip: [15.203.227.10] x-ms-office365-filtering-correlation-id: 05e33362-fe47-4c22-2b2e-08d3ed5da41d x-microsoft-exchange-diagnostics: 1; CS1PR84MB0229; 7:nytQ/u19G/ADH6Q1/lEv6H0ZI84aDc7cN1N5spvtmhMqp8pz52qEXe/rvdpeLRX1k/V1+/keEZAEM7VwhkLGLCo4xfigGM8VIr99bnyuep34r4SiQWvPREfrvOpEx8QRW5inbqWDKFFo2W+9tuuFYpXUbp0yCwLOB6GUDu4nfEmJsNI6vdD/GKlP4svnWBY75qBE3sSWjnmABDJh+ehLBNLJTXzZbqIzTpoE/thw5tJ56W6/kAXOK/84+thA1iBrlmrp4TUOHzCHBt4Cp3sOBhXPtncoIGaa/nom8uD49+eZXrdpt/yL3caswxa173Y8BJGPIZ8bDPhZ56JSdm7m1w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0229; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(180628864354917)(31960201722614)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CS1PR84MB0229; BCL:0; PCL:0; RULEID:; SRVR:CS1PR84MB0229; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(13464003)(189002)(199003)(377454003)(7736002)(2906002)(81166006)(81156014)(8936002)(7846002)(66066001)(92566002)(8666005)(3660700001)(50986999)(54356999)(106356001)(74316002)(76176999)(305945005)(19580395003)(101416001)(87936001)(10400500002)(5002640100001)(9686002)(4326007)(19580405001)(3280700002)(8676002)(5890100001)(86362001)(2950100002)(97736004)(68736007)(6116002)(102836003)(33656002)(586003)(5001770100001)(3846002)(189998001)(7696004)(93886004)(99286002)(77096005)(105586002)(99936001)(11100500001)(2900100001)(122556002)(5660300001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CS1PR84MB0229; H:CS1PR84MB0229.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hpe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 20:24:42.7335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0229 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 20:24:45 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How about moving protocol locate from constructor to the actual function le= vel and returning an error if it fails to locate (See attached patch file). Tapan -----Original Message----- From: Laszlo Ersek [mailto:lersek@redhat.com]=20 Sent: Wednesday, October 05, 2016 3:18 PM To: Andrew Fish ; Daniil Egranov Cc: Carsey, Jaben ; edk2-devel-01 ; Leif Lindholm ; Shah, Tapan Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on= the Reference Platform On 10/05/16 21:48, Andrew Fish wrote: >=20 >> On Oct 5, 2016, at 12:24 PM, Daniil Egranov wro= te: >> >> 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=20 >> requires to execute. In EDK II, it is specified in the [Depex] section o= f INF file. >> >=20 > The Dependency Expression is for DXE Drivers that are dispatched by the D= XE Core. A UEFI Driver from an option ROM or an Application does not get di= spatched by the dispatch and the Depex will not help. The Depex ends up bei= ng a section in the FV and it has nothing to do with the PE/COFF image of t= he an application or option ROM.=20 >=20 > IMHO the shell should try as hard as possible to function and should not = ASSERT if some newer Protocol is missing. =20 (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 copi= ed or moved over -- and can translate the ASCII subset of UCS-2, - once the ASCII characters of the input string have been translated to upp= er 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 suff= ices 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 co= llation protocol (I trust), and no other ASCII characters than n/u/l will t= ranslate to N/U/L. This means that we won't miss an instance of NULL becaus= e 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