Since performance library instances have been updated
to create new FPDT records for new Perf macros.
So enhance dp tool to parse the new FPDT records.
Enhancement mainly includes:
1. parse the single records for PERF_EVENT macro
2. Parse the new added FPDT_DUAL_GUID_STRING_EVENT_RECORD
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Today's implementation returns 0 even when compared files are
different.
The patch returns 27 (SHELL_NOT_QUAL) in such case to follow
the shell spec.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Currently in DP, the Trace mode is enabled by default.
And the profile mode is not implemented. but the help info
of DP tool doesn't match current implementation. Which will
make user confused. So now remove the unused source code
related to the profile mode and update the help information
of DP tool.
V2: Remove the unused code related to profile mode.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Issue:
When run "dp -s" or ("dp -v") command in shell several times,
the summary reuslts are different each time.
The root cause is that the previous global data "SummaryData"
is not cleaned when the dp command is callled next time.
This patch initializes the global data "SummaryData"
when the dp dymanic command is called.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Run dp command now:
Firstly it will get performance records from FPDT and then
parse the DP command. And if encounter invalid parameters,
it will exit directly. Thus the performance records got before
are invalid. And what's worse is that the memory allocated in
getting performance records phase is not freed.
This patch update the code to parse the command firstly and
then get the performance records. And make sure that all the
clean work has been done before exiting.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
1. Separate variable definition and initialization.
2. Make the variable naming following Edk2 rule.
V2: Remove the updates of guard macros in header files.
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Evan Lloyd <evan.lloyd@arm.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
This program is provided to allow examination of ACPI table contents
from the UEFI Shell. This can help with investigations, especially at
that stage where the tables are not enabling an OS to boot.
The program is not exhaustive, and only encapsulates detailed knowledge
of a limited number of table types.
Default behaviour is to display the content of all tables installed.
'Known' table types will be parsed and displayed with descriptions and
field values. Where appropriate a degree of consistency checking is
done and errors may be reported in the output.
Other table types will be displayed as an array of Hexadecimal bytes.
To facilitate debugging, the -s and -d options can be used to generate a
binary file image of a table that can be copied elsewhere for
investigation using tools such as those provided by acpica.org. This is
especially relevant for AML type tables like DSDT and SSDT.
The inspiration for this is the existing smbiosview Debug1 Shell
command.
Many tables are not explicitly handled, in part because no examples are
available for our testing.
The program is designed to be extended to new tables with minimal
effort, and contributions are invited.
Change-Id: Ifa23dc80ab8ab042c56e88424847e796a8122a7c
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
TrEE is deprecated. We need use Tcg2.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
In edit or hexedit, the mouse cursor doesn't move when moving
the mouse.
The root cause is 5563281fa2
* ShellPkg/[hex]edit: use SimpleTextInEx to read console
wrongly uses WaitForEvent() to listen keyboard input.
It blocks the code execution when there is no keyboard input.
While the same function also polls the mouse move status,
the mouse movement cannot be reflected to the screen when
there is no keyboard input.
The patch fixes the issue by use CheckEvent() instead of
WaitForEvent().
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Within function UpdateDisplayFromHistory():
When getting a character with different attribute with the current one,
the statement to compare the character with a 'NULL' char should be:
*StringSegmentEnd != CHAR_NULL
rather than:
StringSegmentEnd != CHAR_NULL
This commit resolves this typo.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Neither the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL nor the EFI_CPU_IO2_PROTOCOL
impose any restrictions when it comes to the range of valid I/O
addresses. Even so, the 'mm' command in -IO mode refuses to perform
accesses to addresses >= 0xffff.
It is not up to 'mm' to impose this restriction, so remove it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Issue:
Reply for first ping packet was getting dropped.
Cause:
Sometimes reply message comes even before trasmit
function returns, hence missing 1st reply
Fix:
Prepare the TxList before calling Transmit function.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
After commit 20ddbc133f
* MdeModulePkg/ConSplitter: ReadKeyStrokeEx always return key state
When one physical console supports to report the shift key state,
the key data returned from ConSplitter driver at least carries
the shift key valid bit.
The patch fixes the edit/hexedit to accept Unicode (1) when
the no shift key is pressed or reported.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
TimerLib had to be resolved in commit 5ab97a64b5 ("ShellPkg/bcfg: Add
Shell Spec 2.2 modification functionality", 2017-03-01) because:
- the BCFG command started making calls to UefiBootManagerLib
(EfiBootManagerVariableToLoadOption(),
EfiBootManagerLoadOptionToVariable(), EfiBootManagerFreeLoadOption()),
- and "MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf"
depended on TimerLib.
Because TimerLib is platform-specific, but "ShellPkg/ShellPkg.dsc" is
meant to produce a UEFI shell binary that is platform-independent (see
"ShellBinPkg/ReadMe.txt"), we resolved TimerLib to
"BaseTimerLibNullTemplate.inf". (TimerLib functionality was never actually
needed on UefiBootManagerLib code paths that were exercised by the shell /
BCFG.)
Thanks to the last patch, UefiBootManagerLib no longer depends on
TimerLib, thus we can drop the TimerLib resolution entirely.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=682
Edit and HexEdit commands assume that SimpleTxtIn translates
Ctrl+<Alpha-Key> key combinations into Unicode control characters
(0x1-0x1A).
Such translation does not seem to be required by the UEFI spec.
Shell should not rely on implementation specific behavior.
It should instead use SimpleTextInEx to read Ctrl+<Alpha-Key> key
combinations.
The patch changes edit and hexedit to only consumes SimpleTextInEx
so that the implementation specific behavior dependency is removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reported-by: Felix <felixp@mail.ru>
Cc: Felix <felixp@mail.ru>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Shell core was enhanced to find the manual string in PE resource
section. But the finding algorithm is too strict: If the manual is
written beginning with:
.TH command 0 "descripton of command"
but user types "COMMAND.efi -?". The finding algorithm uses
case-sensitive compare between "command" and "COMMAND" resulting
in the manual cannot be found.
The patch fixes this issue by using existing ManFileFindTitleSection
and ManFileFindSections which compare command case-insensitive.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Make the error message clearer if fail to get ACPI/FPDT table.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
An ordinary empty directory should contain "." and ".." entries.
When an empty directory even doesn't contain "." or ".." entry,
FileHandleFindFirstFile() may return error status and a NULL
FileInfo.
IsDirectoryEmpty() implementation in Rm.c doesn't consider this
case and the deference of FileInfo->FileName causes page fault
exception because FileInfo is NULL.
The patch checks the return status of FileHandleFindFirstFile()
to fix this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
HDiskImageSetDiskNameOffsetSize() and HFileImageSetFileName()
may be called using the current disk name or file name.
When this happens, today's implementation firstly frees the memory
and then accesses the just-freed memory.
The patch fixes this issue by doing nothing when the disk or file
name is the current one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
"Compress.h" declares the Compress() function as EFIAPI, but the
definition in "Compress.c" lacks EFIAPI.
GCC toolchains without LTO do not catch this error because "Compress.c"
does not include "Compress.h"; i.e. the declaration used by callers such
as "EfiCompress.c" is not actually matched against the function definition
at build time.
With LTO enabled, the mismatch is found -- however, as a warning only, due
to commit f8d0b96629 ("BaseTools GCC5: disable warnings-as-errors for
now", 2016-08-03).
Include the header in the C file (which turns the issue into a hard build
error on all GCC toolchains), plus sync the declaration from the header
file to the C file. Finally, remove EFIAPI from both declaration and
definition -- this was the original intent of commit c4e74e9b81
("ShellPkg/UefiShellDebug1CommandsLib: Remove unnecessary EFIAPI",
2016-10-09), but it missed the header file.
(Gary meant to address that omission in Oct 2017:
[edk2] [PATCH] ShellPkg/UefiShellDebug1CommandsLib: Remove EFIAPI from
Compress()
http://mid.mail-archive.com/20171026065329.32311-1-glin@suse.com
and Ray reviewed the patch, but then the patch was never committed.)
So do the sync and drop EFIAPI now.
This happens to fix the EFICOMPRESS shell command, when built with GCC for
X64.
Cc: Gary Lin <glin@suse.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Fixes: c4e74e9b81
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The below code reads additional one CHAR16 when copying
content from Specific to NewSpecific.
NewSpecific = AllocateCopyPool(
StrSize(Specific) + sizeof(CHAR16), Specific
);
The patch fixes this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
When "FOR %a %a IN A B C" is executed,
CurrentScriptFile->CurrentCommand->Data is NULL.
But the code assumes it's not NULL and tries to
deference it.
The patch fixes this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Original code locates the first UnicodeCollation instance in
DXE Core protocol database.
It's not correct considering multiple UnicodeCollation instances
exist in system.
The patch changes logic to find the one that matches the current
system language.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com.
In the for-loop condition of original code, the expression
*CurrentCommand != CHAR_NULL
is put before expression
CurrentCommand < SortedCommandList + SortedCommandListSize/sizeof(CHAR16)
When CurrentCommand walks to the end of string buffer, one more character
over the end of string buffer will be read and then stop.
To fix this issue, just move the last expression to the first one. Because
of short-circuit evaludation of and-expression, the following one
*CurrentCommand != CHAR_NULL
will not be evaluated if the expression before it is evaludated as FALSE.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
UefiShellLevel2CommandsLib (somewhat questionably) calls the
BaseLib-internal function InternalCharToUpper().
This function is declared in "MdePkg/Library/BaseLib/BaseLibInternals.h",
which is not a public library class header. UefiShellLevel2CommandsLib
therefore duplicates the function declaration, but a mistake was made: the
EFIAPI calling convention is not spelled out on the duplicated
declaration. Therefore calls made from UefiShellLevel2CommandsLib will not
match the actual function definition in "MdePkg/Library/BaseLib/String.c",
when GCC/X64 toolchains are used.
One consequence of this is that cross-filesystem copies don't work in the
UEFI shell (see the StrniCmp() function in
"UefiShellLevel2CommandsLib.c"). From the original report:
> FS0:\efi\ubuntu\> cp grubx64.efi fs1:\
>
> cp: The source and destination are the same.
Copy the declaration from "BaseLibInternals.h" to
"UefiShellLevel2CommandsLib.c" verbatim.
Reported-by: Rebecca Cran <rebecca@bluestop.org>
Analyzed-by: Thomas Palmer <thomas.palmer@hpe.com>
Analyzed-by: Liming Gao <liming.gao@intel.com>
Ref: http://mid.mail-archive.com/47cd17d8-f022-6ca5-2f52-06a8250f8d14@cran.org.uk
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Rebecca Cran <rebecca@bluestop.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Thomas Palmer <thomas.palmer@hpe.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Thomas Palmer <thomas.palmer@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Last check in involved a build error, this patch is to
fix this issue.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan <fan.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Since new Api NetLibDetectMediaWaitTimeout was involved to support connecting
state handling, and it is forward compatible. So apply this Api in ShellPkg.
V2:
*Define time period in a macro instead of hard code.
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan <fan.wang@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Signed-off-by: fanwang2 <fan.wang@intel.com>
When Dynamic command drivers links to ShellLib, the ShellLib
constructor shouldn't be called because the Shell and ShellParameters
protocols don't exist when the driver starts.
So it's required to set PcdShellLibAutoInitialize to FALSE for
dynamic command drivers.
Update the comments in DEC file to describe such requirement
for this PCD.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
When dynamic command drivers are built into FV and start during
boot, they fails. Because Shell protocol doesn't exist during boot.
The patch sets Shell protocol and also set PcdShellLibAutoInitialize
to FALSE to ensure that
1. Shell protocol check doesn't happen in driver's entry point.
2. Driver can get the Shell protocol in DynamicCommand.Handler().
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The previous change in ShellLib: "commit
3d29f8c5e3
* ShellPkg/ShellLib: Constructor doesn't depend on ShellParameters"
resolved the issue when loading dynamic command driver from Shell
environment.
But when dynamic command driver is built into FV and started during
boot, the driver still fails to start because Shell protocol doesn't
exist at that time.
The patch changes ShellLib to:
1. Do not look for Shell and ShellParameters protocol when they are
non-NULL in ShellLibConstructorWorker();
The two protocols are assumed to be set by DynamicCommand.Handler.
When ShellInitialize() is called in DynamicCommand.Handler, this
change can prevent the two protocols to be changed to NULL by
the locating logic.
2. Do not reset the Shell and ShellParameters protocol to NULL in
ShellLibDestructor() when CloseProtocol() fails;
Dynamic command driver needs to set the PcdShellLibAutoInitialize
to FALSE in order to skip the constructor.
Current logic calls ShellLibDestructor() when the PCD is FALSE when
ShellInitialize() is called. The change prevent the two protocols
to be changed to NULL.
The two changes don't impact existing usage case so they are backward
compatible.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Current implementation resets the CTRL-C event early when printing
the shell prompt, when user types "<CTRL-C>ls<ENTER>", "ls" command
is terminated immediately when starts.
It's not an expected behavior from users' perspective.
Correct way is to reset the CTRL-C event just before running the
command, which is a bit later than current point.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
UEFI Shell spec defines Shell Dynamic Command protocol which is just
for the purpose to extend internal command.
So dp command is changed from NULL class library to be a driver
producing DynamicCommand protocol.
The guideline is:
1. Only use NULL class library for Shell spec defined commands.
2. New commands can be provided as not only a standalone application
but also a dynamic command. So it can be used either as an
internal command, but also as a standalone application.
DpApp.inf is to provide a standalone application.
DpDynamicCommand.inf is to provide a standalone driver producing
Dynamic Command protocol.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
UEFI Shell spec defines Shell Dynamic Command protocol which is just
for the purpose to extend internal command.
So tftp command is changed from NULL class library to be a driver
producing DynamicCommand protocol.
The guideline is:
1. Only use NULL class library for Shell spec defined commands.
2. New commands can be provided as not only a standalone application
but also a dynamic command. So it can be used either as an
internal command, but also as a standalone application.
TftpApp.inf is to provide a standalone application.
TftpDynamicCommand.inf is to provide a standalone driver producing
Dynamic Command protocol.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
When ShellLib is linked to a driver producing DynamicCommand
protocol, ShellParameters protocol is set by
DynamicCommand.Handler().
The driver image handle doesn't have ShellParameters protocol
installed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=779
For the API EfiShellOpenRootByHandle():
The return status of the call to SimpleFileSystem->OpenVolume should be
checked.
It is possible that there is a media change in the device (like CD/DVD
ROM). In such case, the volume root opened and/or the device path opened
previously (also within EfiShellOpenRootByHandle) may be invalid.
This commit adds a check for the result of OpenVolume before subsequently
calling functions like EfiShellGetMapFromDevicePath() &
ConvertEfiFileProtocolToShellHandle().
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
V2:
Fix MSFT C4255 warning
V1:
Enable MSFT C4255 warning.
From MSDN:
Compiler Warning (level 4) C4255
function' : no function prototype given: converting '()' to '(void)'
The compiler did not find an explicit list of arguments to a function.
This warning is for the C compiler only.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song <binx.song@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
AllocateCopyPool(AllocationSize, *Buffer) will copy "AllocationSize" bytes of
memory from old "Buffer" to new allocated one. If "AllocationSize" is bigger
than size of "Buffer", heap memory overflow occurs during copy.
One solution is to allocate pool first then copy the necessary bytes to new
memory. Another is using ReallocatePool instead if old buffer will be freed
on spot.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Bi Dandan <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
EfiCpuIoWidthUint8 should be used in HMemImageRead and HMemImageSave.
Because CpuIo protocol is now used for memory access.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The original code uses PciRootBridgeIo for memory access.
It worked before MdeModulePkg/PciHostBridgeDxe driver was checked in.
But MdeModulePkg/PciHostBridgeDxe adds checks to ensure the MMIO
access request is in the scope of the current RootBridgeIo instance.
It causes "hexeditor -m 0 2" reports error because memory address 0
surely is not in the scope of any RootBridgeIo instance.
In fact only accessing the MMIO space occupied by the RootBridgeIo
can work.
The patch changes hexeditor to use CpuIo for memory access.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The original code as below intend to set the character
before last column to CHAR_NULL.
Line[(LastCol % (ARRAY_SIZE (Line) - 1)) - 1] = CHAR_NULL;
But when LastCol % (ARRAY_SIZE (Line) - 1)) equals to 0,
Line[-1] is modified.
We should change to code as below:
Line[(LastCol - 1) % (ARRAY_SIZE (Line) - 1)] = CHAR_NULL;
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Bi, Dandan
Ruiyu Ni
Jiewen Yao
Hao Wu
Ard Biesheuvel
Meenakshi Aggarwal
Laszlo Ersek
Jian J Wang
fanwang2
Fu Siyuan
Song, BinX