From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <jaben.carsey@intel.com> Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 A05D821A0483B for <edk2-devel@lists.01.org>; Wed, 19 Apr 2017 10:48:35 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 10:48:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,222,1488873600"; d="scan'208";a="76368335" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 19 Apr 2017 10:48:35 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 19 Apr 2017 10:48:34 -0700 Received: from fmsmsx103.amr.corp.intel.com ([169.254.2.246]) by FMSMSX109.amr.corp.intel.com ([169.254.15.83]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 10:48:34 -0700 From: "Carsey, Jaben" <jaben.carsey@intel.com> To: Jeff Westfahl <jeff.westfahl@ni.com>, "edk2-devel@lists.01.org" <edk2-devel@lists.01.org> CC: "Ni, Ruiyu" <ruiyu.ni@intel.com> Thread-Topic: [edk2] ShellPkg: Difference in behavior of 'dh' between old shell and new Thread-Index: AQHSuTN4oDVBGvLT70ic3rGp6F7BbaHM9roA Date: Wed, 19 Apr 2017 17:48:34 +0000 Message-ID: <CB6E33457884FA40993F35157061515C54C08ABC@FMSMSX103.amr.corp.intel.com> References: <alpine.DEB.2.20.1704191228390.2233@jmw-lm181> In-Reply-To: <alpine.DEB.2.20.1704191228390.2233@jmw-lm181> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.1.200.108] MIME-Version: 1.0 Subject: Re: ShellPkg: Difference in behavior of 'dh' between old shell and new X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development <edk2-devel.lists.01.org> List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>, <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe> List-Archive: <http://lists.01.org/pipermail/edk2-devel/> List-Post: <mailto:edk2-devel@lists.01.org> List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help> List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>, <mailto:edk2-devel-request@lists.01.org?subject=subscribe> X-List-Received-Date: Wed, 19 Apr 2017 17:48:35 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That would be welcome; I don't know how it was missed. A caveat is that th= e shell should use UEFI protocols only. No PI protocols can be required (o= ptional is ok). Only the specific output controlled by "-sfo" is severely constrained by th= e spec. > -----Original Message----- > From: Jeff Westfahl [mailto:jeff.westfahl@ni.com] > Sent: Wednesday, April 19, 2017 10:36 AM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben <jaben.carsey@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com= > > Subject: [edk2] ShellPkg: Difference in behavior of 'dh' between old shel= l and > new > Importance: High >=20 > I noticed a difference in behavior of 'dh' between the old shell and the = new shell. > With the old shell, 'dh -v' for a LoadedImage handle shows the > following: >=20 > Handle D3 (3A537F98) > Image (3A532818) File:MicrocodeUpdate > ParentHandle..: 3A64F118 > SystemTable...: 3D2A8F18 > DeviceHandle..: 3B1B2098 > FilePath......: FvFile(F3331DE6-4A55-44E4-B767-7453F7A1A021) > ImageBase.....: 3D650000 - 3D655540 > ImageSize.....: 5540 > CodeType......: RT_code > DataType......: RT_data >=20 > With the new shell, I get this for the same LoadedImage handle: >=20 > D3: 3A537F98 > LoadedImage > Revision......: 0x00001000 > ParentHandle..: 3A64F118 > SystemTable...: 3D2A8F18 > DeviceHandle..: 3B1B2098 > FilePath......: 3A539018 > OptionsSize...: 0 > LoadOptions...: 0 > ImageBase.....: 3D650000 > ImageSize.....: 5540 > CodeType......: EfiRuntimeServicesCode > DataType......: EfiRuntimeServicesData > Unload........: 0 >=20 > The old shell shows the name of the file associated with the LoadedImage, > which seems like useful information. Is this omission intentional or an o= versight? > Would a patch adding the file name to ShellPkg be welcomed? >=20 > Regards, > Jeff