From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from msmail.insydesw.com.tw (ms.insydesw.com [211.75.113.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3EBFB20D77DC5 for ; Wed, 5 Apr 2017 09:39:08 -0700 (PDT) Received: from msmail.insydesw.com.tw ([fe80::74f7:f173:f4aa:9a05]) by msmail.insydesw.com.tw ([fe80::74f7:f173:f4aa:9a05%11]) with mapi id 14.01.0438.000; Thu, 6 Apr 2017 00:39:05 +0800 From: Tim Lewis To: "Jim.Dailey@dell.com" , "jaben.carsey@intel.com" , "ruiyu.ni@intel.com" CC: "edk2-devel@lists.01.org" Thread-Topic: UEFI Shell Lib Constructor and Shell Parameters Protocol Thread-Index: AdKuFe4dMrnMRkXwRa+ni64zpaOLZAACDXMAAABUXxAAAtOHoA== Date: Wed, 5 Apr 2017 16:39:04 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F566D45@msmail.insydesw.com.tw> References: <2acd9ee552f944598f9716c2f81780cc@ausx13mps335.AMER.DELL.COM> In-Reply-To: <2acd9ee552f944598f9716c2f81780cc@ausx13mps335.AMER.DELL.COM> Accept-Language: en-US, zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.9.114] 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 16:39:08 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are "load options" that are passed to drivers (as a part of the EFI_L= OADED_IMAGE_PROTOCOL), but there is no guarantee as to their format (binary= data or ASCII string or UCS-2 string). It is possible for "load" to be mod= ified to create this data and populate it between the calls to LoadImage() = and StartImage() as the shell does, but that isn't spec. Tim -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Jim.= Dailey@dell.com Sent: Wednesday, April 05, 2017 8:21 AM To: jaben.carsey@intel.com; ruiyu.ni@intel.com Cc: edk2-devel@lists.01.org Subject: Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protoco= l Thanks, Jaben. That makes sense. Now I see the real issue is with the "app" I ran across. It is a driver, a= nd it was trying to access command line args. The driver crashed when it t= ried 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 dr= iver, and as a result, it apparently doesn't load the shell parameters prot= ocol on the driver's handle, which caused the crash. Regards, Jim -----Original Message----- From: Carsey, Jaben [mailto:jaben.carsey@intel.com] 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=20 > Jim.Dailey@dell.com > Sent: Wednesday, April 05, 2017 7:07 AM > To: Carsey, Jaben ; Ni, Ruiyu=20 > > Cc: edk2-devel@lists.01.org > Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters=20 > 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=20 > 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=20 > is made to locate it---the code simply leaves the parameters protocol=20 > 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=20 > add code to try and locate the parameters protocol, then the app works=20 > as designed WRT accessing command line parameters. Is there some=20 > lurking issue if an attempt to locate the parameters protocol is made=20 > 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel