From: <Jim.Dailey@dell.com>
To: <jaben.carsey@intel.com>, <ruiyu.ni@intel.com>
Cc: <edk2-devel@lists.01.org>
Subject: Re: UEFI Shell Lib Constructor and Shell Parameters Protocol
Date: Wed, 5 Apr 2017 15:21:19 +0000 [thread overview]
Message-ID: <2acd9ee552f944598f9716c2f81780cc@ausx13mps335.AMER.DELL.COM> (raw)
In-Reply-To: <CB6E33457884FA40993F35157061515C54BDB6C3@FMSMSX103.amr.corp.intel.com>
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]
Sent: Wednesday, April 5, 2017 10:08 AM
To: Dailey, Jim <Jim_Dailey@Dell.com>; Ni, Ruiyu <ruiyu.ni@intel.com>
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 it 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 <jaben.carsey@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol
> Importance: High
>
>
> A question or two for all shell experts:
>
> 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".
>
> 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?
>
> 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?
>
> Thanks,
> Jim
>
> -------
> Here is the relevant code:
>
> EFI_STATUS
> ShellLibConstructorWorker (
> IN EFI_HANDLE ImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> EFI_STATUS Status;
>
> //
> // UEFI 2.0 shell interfaces (used preferentially)
> //
> Status = gBS->OpenProtocol(
> ImageHandle,
> &gEfiShellProtocolGuid,
> (VOID **)&gEfiShellProtocol,
> ImageHandle,
> NULL,
> EFI_OPEN_PROTOCOL_GET_PROTOCOL
> );
> if (EFI_ERROR(Status)) {
> //
> // Search for the shell protocol
> //
> Status = gBS->LocateProtocol(
> &gEfiShellProtocolGuid,
> NULL,
> (VOID **)&gEfiShellProtocol
> );
> if (EFI_ERROR(Status)) {
> gEfiShellProtocol = NULL;
> }
> }
> Status = 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 = gBS->LocateProtocol(
> &gEfiShellParametersProtocolGuid,
> NULL,
> (VOID **)&gEfiShellParametersProtocol
> );
> if (EFI_ERROR(Status)) {
> gEfiShellParametersProtocol = NULL;
> }
> #else
> gEfiShellParametersProtocol = NULL;
> #endif
> }
> ...
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2017-04-05 15:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-05 14:07 UEFI Shell Lib Constructor and Shell Parameters Protocol Jim.Dailey
2017-04-05 15:08 ` Carsey, Jaben
2017-04-05 15:21 ` Jim.Dailey [this message]
2017-04-05 16:08 ` Carsey, Jaben
2017-04-05 16:39 ` Tim Lewis
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=2acd9ee552f944598f9716c2f81780cc@ausx13mps335.AMER.DELL.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