* UEFI Shell Lib Constructor and Shell Parameters Protocol
@ 2017-04-05 14:07 Jim.Dailey
2017-04-05 15:08 ` Carsey, Jaben
0 siblings, 1 reply; 5+ messages in thread
From: Jim.Dailey @ 2017-04-05 14:07 UTC (permalink / raw)
To: jaben.carsey, ruiyu.ni; +Cc: edk2-devel
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
}
...
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UEFI Shell Lib Constructor and Shell Parameters Protocol
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
0 siblings, 1 reply; 5+ messages in thread
From: Carsey, Jaben @ 2017-04-05 15:08 UTC (permalink / raw)
To: Jim.Dailey@dell.com, Ni, Ruiyu; +Cc: edk2-devel@lists.01.org
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UEFI Shell Lib Constructor and Shell Parameters Protocol
2017-04-05 15:08 ` Carsey, Jaben
@ 2017-04-05 15:21 ` Jim.Dailey
2017-04-05 16:08 ` Carsey, Jaben
2017-04-05 16:39 ` Tim Lewis
0 siblings, 2 replies; 5+ messages in thread
From: Jim.Dailey @ 2017-04-05 15:21 UTC (permalink / raw)
To: jaben.carsey, ruiyu.ni; +Cc: edk2-devel
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UEFI Shell Lib Constructor and Shell Parameters Protocol
2017-04-05 15:21 ` Jim.Dailey
@ 2017-04-05 16:08 ` Carsey, Jaben
2017-04-05 16:39 ` Tim Lewis
1 sibling, 0 replies; 5+ messages in thread
From: Carsey, Jaben @ 2017-04-05 16:08 UTC (permalink / raw)
To: Jim.Dailey@dell.com, Ni, Ruiyu; +Cc: edk2-devel@lists.01.org
Glad to help.
I do not think that UEFI drivers really have the concept of command line parameters... they use other methods for configuration...
-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 8:21 AM
> To: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] UEFI Shell Lib Constructor and Shell Parameters Protocol
> Importance: High
>
> 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
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: UEFI Shell Lib Constructor and Shell Parameters Protocol
2017-04-05 15:21 ` Jim.Dailey
2017-04-05 16:08 ` Carsey, Jaben
@ 2017-04-05 16:39 ` Tim Lewis
1 sibling, 0 replies; 5+ messages in thread
From: Tim Lewis @ 2017-04-05 16:39 UTC (permalink / raw)
To: Jim.Dailey@dell.com, jaben.carsey@intel.com, ruiyu.ni@intel.com
Cc: edk2-devel@lists.01.org
There are "load options" that are passed to drivers (as a part of the EFI_LOADED_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 modified 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 Protocol
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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-04-05 16:39 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2017-04-05 16:08 ` Carsey, Jaben
2017-04-05 16:39 ` Tim Lewis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox