From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 191B820D77DA5 for ; Wed, 5 Apr 2017 08:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1491405267; x=1522941267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AmWE0kFTE9WYWBnp0Am0a88q8l9lmwGDEBXVNEaabVg=; b=PXCjQ7rsEgRKfjAmcNCgeplt3d8jnMl0vGnI0t6LzCvk1vU1AWdWbSN2 iX5dkyF6dKbhOd0G2ENqcRtQ7KIXmBcRvQbNro/GIJb5KkTXQQA0jiGep D6wX1ghKr/0/8MWJSh7CPBA+a7LOolUQH2lH5SxO9Kb4dwM70zwX2q6oS Y=; Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2017 10:14:26 -0500 From: Received: from ausc60pc101.us.dell.com ([143.166.85.206]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2017 21:20:18 +0600 X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.36,279,1486447200"; d="scan'208";a="1096146052" To: , CC: Thread-Topic: UEFI Shell Lib Constructor and Shell Parameters Protocol Thread-Index: AdKuFe4dMrnMRkXwRa+ni64zpaOLZAACDXMAAABUXxA= Date: Wed, 5 Apr 2017 15:21:19 +0000 Message-ID: <2acd9ee552f944598f9716c2f81780cc@ausx13mps335.AMER.DELL.COM> References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titusconfig: No Restrictions 04051212 x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvIiwiaWQiOiJjMDdjNGM5OS1kNWM0LTQyOWYtYjFhZi03OTBlOWE1ZmY1NjgiLCJwcm9wcyI6W3sibiI6IkNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJObyBSZXN0cmljdGlvbnMifV19LHsibiI6IlN1YmxhYmVscyIsInZhbHMiOltdfSx7Im4iOiJFeHRlcm5hbENvcnJlc3BvbmRlbmNlIiwidmFscyI6W119XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTYuMi4xMS4wIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImhYdHFnbFFycTFXOHkzTmpkSFQ1QUw1UEpjeEIxSGRaTkN4bmd1RGF3ZWs9In0= x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.210.125.233] MIME-Version: 1.0 Subject: Re: UEFI Shell Lib Constructor and Shell Parameters Protocol X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:21:29 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Jaben. That makes sense. Now I see the real issue is with the "app" I ran across. It is a driver, and it was trying to access command line args. The driver crashed when it tried to access the command line, but it had been loaded in memory via the "load" command. So, it seems "load" has no mechanism to pass command line arguments to a driver, and as a result, it apparently doesn't load the shell parameters protocol on the driver's handle, which caused the crash. Regards, Jim -----Original Message----- From: Carsey, Jaben [mailto:jaben.carsey@intel.com]=20 Sent: Wednesday, April 5, 2017 10:08 AM To: Dailey, Jim ; Ni, Ruiyu Cc: edk2-devel@lists.01.org Subject: RE: UEFI Shell Lib Constructor and Shell Parameters Protocol Jim, That protocol must be installed on your applications own image handle for i= t to be valid. Locating the protocol on some other image would result with= finding the other image's command line parameters and the like... -Jaben > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > Jim.Dailey@dell.com > Sent: Wednesday, April 05, 2017 7:07 AM > To: Carsey, Jaben ; Ni, Ruiyu > Cc: edk2-devel@lists.01.org > Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol > Importance: High >=20 >=20 > A question or two for all shell experts: >=20 > In the UEFI Shell Lib constructor code, if the Shell protocol cannot > be opened, then an attempt is made to locate it before "giving up". >=20 > However, if the Shell parameters protocol cannot be opened, no attempt > is made to locate it---the code simply leaves the parameters protocol > pointer set to NULL. Can anyone explain why this is? >=20 > I came across an app that crashes because of this behavior, but if I > add code to try and locate the parameters protocol, then the app works > as designed WRT accessing command line parameters. Is there some > lurking issue if an attempt to locate the parameters protocol is made > and is successful? >=20 > Thanks, > Jim >=20 > ------- > Here is the relevant code: >=20 > EFI_STATUS > ShellLibConstructorWorker ( > IN EFI_HANDLE ImageHandle, > IN EFI_SYSTEM_TABLE *SystemTable > ) > { > EFI_STATUS Status; >=20 > // > // UEFI 2.0 shell interfaces (used preferentially) > // > Status =3D gBS->OpenProtocol( > ImageHandle, > &gEfiShellProtocolGuid, > (VOID **)&gEfiShellProtocol, > ImageHandle, > NULL, > EFI_OPEN_PROTOCOL_GET_PROTOCOL > ); > if (EFI_ERROR(Status)) { > // > // Search for the shell protocol > // > Status =3D gBS->LocateProtocol( > &gEfiShellProtocolGuid, > NULL, > (VOID **)&gEfiShellProtocol > ); > if (EFI_ERROR(Status)) { > gEfiShellProtocol =3D NULL; > } > } > Status =3D gBS->OpenProtocol( > ImageHandle, > &gEfiShellParametersProtocolGuid, > (VOID **)&gEfiShellParametersProtocol, > ImageHandle, > NULL, > EFI_OPEN_PROTOCOL_GET_PROTOCOL > ); > if (EFI_ERROR(Status)) { > #if 1 // _Dell_ : Search for the parameters protocol too! > // > // Search for the shell parameters protocol > // > Status =3D gBS->LocateProtocol( > &gEfiShellParametersProtocolGuid, > NULL, > (VOID **)&gEfiShellParametersProtocol > ); > if (EFI_ERROR(Status)) { > gEfiShellParametersProtocol =3D NULL; > } > #else > gEfiShellParametersProtocol =3D NULL; > #endif > } > ... > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel