Date   

Re: 回复: [edk2-devel] [PATCH v1 1/1] Pytool: SpellCheck: Fix incorrect file mask across package matrices

Kun Qin
 

Thanks for the review, Liming. Could you please help merging this patch to the master when you have a chance?

Thanks in advance!
Kun

On 06/10/2021 20:23, gaoliming wrote:
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Kun Qin
发送时间: 2021年6月10日 9:48
收件人: devel@edk2.groups.io
抄送: Sean Brogan <sean.brogan@microsoft.com>; Bret Barkelew
<Bret.Barkelew@microsoft.com>; Michael D Kinney
<michael.d.kinney@intel.com>; Liming Gao <gaoliming@byosoft.com.cn>
主题: [edk2-devel] [PATCH v1 1/1] Pytool: SpellCheck: Fix incorrect file
mask
across package matrices

From: Sean Brogan <spbrogan@live.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3443

Existing implementation could modify class global data that causes
potential incorrect file mask to be used for execution of plugin.

This change switches class variable to be tuple so that it cannot be
accidently modified. Local usage of STANDARD_PLUGIN_DEFINED_PATHS is
also
changed to copy to new list before modification.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>

Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
---
.pytool/Plugin/SpellCheck/SpellCheck.py | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/.pytool/Plugin/SpellCheck/SpellCheck.py
b/.pytool/Plugin/SpellCheck/SpellCheck.py
index 43365441b91c..9ad57632a6e8 100644
--- a/.pytool/Plugin/SpellCheck/SpellCheck.py
+++ b/.pytool/Plugin/SpellCheck/SpellCheck.py
@@ -37,12 +37,12 @@ class SpellCheck(ICiBuildPlugin):
#
# A package can remove any of these using IgnoreStandardPaths
#
- STANDARD_PLUGIN_DEFINED_PATHS = ["*.c", "*.h",
+ STANDARD_PLUGIN_DEFINED_PATHS = ("*.c", "*.h",
"*.nasm", "*.asm", "*.masm",
"*.s",
"*.asl",
"*.dsc", "*.dec", "*.fdf",
"*.inf",
"*.md", "*.txt"
- ]
+ )

def GetTestName(self, packagename: str, environment: VarDict) ->
tuple:
""" Provide the testcase name and classname for use in reporting
@@ -107,7 +107,8 @@ class SpellCheck(ICiBuildPlugin):
version_aggregator.GetVersionAggregator().ReportVersion(
"CSpell", cspell_version,
version_aggregator.VersionTypes.INFO)

- package_relative_paths_to_spell_check =
SpellCheck.STANDARD_PLUGIN_DEFINED_PATHS
+ # copy the default as a list
+ package_relative_paths_to_spell_check =
list(SpellCheck.STANDARD_PLUGIN_DEFINED_PATHS)

#
# Allow the ci.yaml to remove any of the above standard paths
--
2.31.1.windows.1




Re: CI is failing - June 2021

Kun Qin
 

Thanks for the heads up, Sean.

The patch series was just sent for review: https://edk2.groups.io/g/devel/message/76419.

The PR that passes all checks against this branch is here: https://github.com/tianocore/edk2/pull/1705

Any feedback is appreciated.

Regards,
Kun

On 06/11/2021 20:41, Sean wrote:
The CI system is failing around the spellcheck plugin.
https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=23772&view=results The patch never got merged (15 months ago and again 8 months ago) to update nodejs to a newer version.  See bug https://bugzilla.tianocore.org/show_bug.cgi?id=2618
This has now caused the spell checker to stop working and is then causing an error which is breaking the CI builds.
Updating Node resolves this error.
But after updating a few packages fail because of spelling errors. ArmPkg, ArmPlatformPkg, and StandaloneMMPkg.
More info being tracked in this
https://bugzilla.tianocore.org/show_bug.cgi?id=3445
Please prioritize reviewing the patch series that will be sent out soon
FYI - There is also another bug that is hiding a few of the spelling failures on linux machines.
https://bugzilla.tianocore.org/show_bug.cgi?id=3454
Thanks
Sean


[PATCH v1 4/4] Azurepipeline: SpellCheck: Enforce Node dependency to use version 14.x

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445

Per update from Cspell tool, the minimal requirement of Cspell 5.x
regarding Node is 12 and above. This has caused multple Cspell failures
during CI build validation:
"Failed to process "**.c" TypeError: text.matchAll(...) is not a function
or its return value is not iterable"

This change updates the lowest required node version to 14.x to support
Cspell functionalities.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
---
.azurepipelines/templates/spell-check-prereq-steps.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.azurepipelines/templates/spell-check-prereq-steps.yml b/.azurepipelines/templates/spell-check-prereq-steps.yml
index e1570d4f2aac..98ee3cfa6bc6 100644
--- a/.azurepipelines/templates/spell-check-prereq-steps.yml
+++ b/.azurepipelines/templates/spell-check-prereq-steps.yml
@@ -13,7 +13,7 @@ parameters:
steps:
- task: NodeTool@0
inputs:
- versionSpec: '10.x'
+ versionSpec: '14.x'
#checkLatest: false # Optional
condition: and(gt(variables.pkg_count, 0), succeeded())

--
2.31.1.windows.1


[PATCH v1 3/4] ArmPkg: SpellCheck: Update valid acronyms in ExtendedWords

Kun Qin
 

From: Sean Brogan <sean.brogan@microsoft.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445

Spellcheck was not covering all specified files due to CSpell v5 and
Node v10 incompatibility of current CI pipeline configuration.

This change updates ExtendedWords for ArmPkg with valid acronyms to avoid
potential spell errors.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
---
ArmPkg/ArmPkg.ci.yaml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/ArmPkg/ArmPkg.ci.yaml b/ArmPkg/ArmPkg.ci.yaml
index d91c03f2acb8..a0d6a75fe881 100644
--- a/ArmPkg/ArmPkg.ci.yaml
+++ b/ArmPkg/ArmPkg.ci.yaml
@@ -94,13 +94,18 @@
"ackintid",
"actlr",
"aeabi",
+ "asedis",
"ashldi",
"ashrdi",
+ "baddr",
"ccidx",
"ccsidr",
"clidr",
"clrex",
"clzsi",
+ "cnthctl",
+ "cortexa",
+ "cpacr",
"cpuactlr",
"csselr",
"ctzsi",
@@ -116,6 +121,7 @@
"divdi",
"divsi",
"dmdepkg",
+ "dpref",
"drsub",
"fcmpeq",
"fcmpge",
@@ -125,17 +131,25 @@
"ffreestanding",
"frsub",
"hisilicon",
+ "iccabpr",
"iccbpr",
"icciar",
"iccicr",
"icciidr",
+ "iccpir",
"iccpmr",
+ "iccrpr",
+ "icdabr",
"icdicer",
"icdicfr",
+ "icdicpr",
"icdictr",
+ "icdiidr",
"icdiser",
"icdisr",
+ "icdppisr",
"icdsgir",
+ "icdspr",
"icenabler",
"intid",
"ipriority",
@@ -160,6 +174,7 @@
"lshrdi",
"moddi",
"modsi",
+ "mpcore",
"mpidr",
"muldi",
"mullu",
@@ -168,6 +183,9 @@
"nsasedis",
"nuvia",
"oldit",
+ "pcten",
+ "plpis",
+ "procno",
"readc",
"revsh",
"rfedb",
@@ -189,6 +207,7 @@
"smmlsr",
"sourcery",
"srsdb",
+ "ssacr",
"stmdb",
"stmia",
"strbt",
--
2.31.1.windows.1


[PATCH v1 2/4] ArmPlatformPkg: SpellCheck: Switch spellcheck CI to AuditOnly

Kun Qin
 

From: Sean Brogan <sean.brogan@microsoft.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445

Spellcheck was not covering all specified files due to CSpell v5 and
Node v10 incompatibility of current CI pipeline configuration.

This change switches the spellcheck for ArmPlatformPkg to AuditOnly to
avoid potentially numerous spell errors. The correction action is to be
revisited by package maintainers once the tool incompatibility is
resolved.

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
---
ArmPlatformPkg/ArmPlatformPkg.ci.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.ci.yaml b/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
index 1abaa2f6870c..3dbbcc673bf0 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
+++ b/ArmPlatformPkg/ArmPlatformPkg.ci.yaml
@@ -83,7 +83,7 @@

## options defined .pytool/Plugin/SpellCheck
"SpellCheck": {
- "AuditOnly": False,
+ "AuditOnly": True,
"IgnoreFiles": [], # use gitignore syntax to ignore errors
# in matching files
"ExtendWords": [
--
2.31.1.windows.1


[PATCH v1 1/4] StandaloneMmPkg: Core: Spelling error in comment

Kun Qin
 

From: Sean Brogan <sean.brogan@microsoft.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445

This change fixed a misspelling that was not caught by spell check.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>

Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
---
StandaloneMmPkg/Core/Dispatcher.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/StandaloneMmPkg/Core/Dispatcher.c b/StandaloneMmPkg/Core/Dispatcher.c
index dbd5332fa9d3..7e4bf5e94025 100644
--- a/StandaloneMmPkg/Core/Dispatcher.c
+++ b/StandaloneMmPkg/Core/Dispatcher.c
@@ -4,7 +4,7 @@
Step #1 - When a FV protocol is added to the system every driver in the FV
is added to the mDiscoveredList. The Before, and After Depex are
pre-processed as drivers are added to the mDiscoveredList. If an Apriori
- file exists in the FV those drivers are addeded to the
+ file exists in the FV those drivers are added to the
mScheduledQueue. The mFwVolList is used to make sure a
FV is only processed once.

--
2.31.1.windows.1


[PATCH v1 0/4] Update Node to 14.x to resolve cspell failure

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445

According to requirements set by cspell, the minimal node version to
support cspell v5+ should be 12 or above (ref:
https://github.com/streetsidesoftware/cspell/tree/main/packages/cspell).

This mismatched dependency caused "Failed to process "**" TypeError:
text.matchAll(...) is not a function or its return value is not iterable"
errors on multiple files during spell check, and they have been ignored
silently.

This change will update the node dependency to be at least v14 to fix
incompatibility issue. With this resolved, the newly discovered
misspellings are handled accordingly:
* Spelling error in StandaloneMM get fixed.
* Spelling errors in ArmPkg are added to package config for their validity.
* Spelling errors in ArmPlatformPkg is set to audit mode and request the
maintainers resolve the errors.

Patch v1 branch: https://github.com/kuqin12/edk2/tree/node_14_v1

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>

Kun Qin (1):
Azurepipeline: SpellCheck: Enforce Node dependency to use version 14.x

Sean Brogan (3):
StandaloneMmPkg: Core: Spelling error in comment
ArmPlatformPkg: SpellCheck: Switch spellcheck CI to AuditOnly
ArmPkg: SpellCheck: Update valid acronyms in ExtendedWords

StandaloneMmPkg/Core/Dispatcher.c | 2 +-
.azurepipelines/templates/spell-check-prereq-steps.yml | 2 +-
ArmPkg/ArmPkg.ci.yaml | 19 +++++++++++++++++++
ArmPlatformPkg/ArmPlatformPkg.ci.yaml | 2 +-
4 files changed, 22 insertions(+), 3 deletions(-)

--
2.31.1.windows.1


CI is failing - June 2021

Sean
 

The CI system is failing around the spellcheck plugin.
https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=23772&view=results


The patch never got merged (15 months ago and again 8 months ago) to update nodejs to a newer version. See bug https://bugzilla.tianocore.org/show_bug.cgi?id=2618

This has now caused the spell checker to stop working and is then causing an error which is breaking the CI builds.
Updating Node resolves this error.

But after updating a few packages fail because of spelling errors. ArmPkg, ArmPlatformPkg, and StandaloneMMPkg.

More info being tracked in this
https://bugzilla.tianocore.org/show_bug.cgi?id=3445

Please prioritize reviewing the patch series that will be sent out soon

FYI - There is also another bug that is hiding a few of the spelling failures on linux machines.
https://bugzilla.tianocore.org/show_bug.cgi?id=3454



Thanks
Sean


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 4:29 PM, Ethin Probst <harlydavidsen@...> wrote:

Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!


OK that makes sense. The address in the add-symbol-file command is not the load address of the image, but the start address of the text section. So that is why you had to add 0x240. 

Sorry I had to work backwards from how it works, but maybe that info will be helpful for others?

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...>
wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0  0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()
#5  0x000000007feab5c7 in ?? ()
#6  0x000000007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2   GCC inline implementation of BaseLib processor specific functions.
3
4   Copyright (c) 2006 - 2020, Intel Corporation. All rights
reserved.<BR>
5   Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6   SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug

OK that is interesting…. +576 -> 0x240 witch is about the size of the
PE/COFF header.

For mach-O (macOS executables) we have to link at 0x240 to make space for
the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section
starts at 0x7e4b8240? So try adding 0x240 to the load address on the
add-symbol-file command. If that does not work trip subtracting 0x240 from
the load address.

We would need to dump out the UsbAudio.efi file to figure out exactly what
is going on. What distro are you on? Do you have the readpe utility? I’m not
sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB
myself.
:)

What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There
is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote
9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>
<mailto:afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>
<mailto:harlydavidsen@... <mailto:harlydavidsen@...>>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>) like this (from the main
EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers
and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the
image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump
into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might
be
a
little off on gdb specifics…. Also my terminology may be lldb
centric.

Easy one 1st. When you run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath  the exception 3 is going to get
handled
in
the unexpected exception handler, and that is probably in the CPUD
DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU
acts
a
lot
more like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the
CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target
for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is
a
handshake that describes the target and what registers are
available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So
this
changing the target definition might confuse the debugger. To be
safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the
debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst




-- 
Signed,
Ethin D. Probst




Re: Help with debugging

Ethin Probst
 

Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!

On 6/11/21, Andrew Fish <afish@apple.com> wrote:


On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug"
at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from
Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0 0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1 ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2 _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at
/home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3 0x000000007fead316 in ?? ()
#4 0x000000007e4f7518 in ?? ()
#5 0x000000007feab5c7 in ?? ()
#6 0x000000007fea3520 in ?? ()
#7 0x0000000101000000 in ?? ()
#8 0x0000000000000030 in ?? ()
#9 0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2 GCC inline implementation of BaseLib processor specific functions.
3
4 Copyright (c) 2006 - 2020, Intel Corporation. All rights
reserved.<BR>
5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights
reserved.<BR>
6 SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
OK that is interesting…. +576 -> 0x240 witch is about the size of the
PE/COFF header.

For mach-O (macOS executables) we have to link at 0x240 to make space for
the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section
starts at 0x7e4b8240? So try adding 0x240 to the load address on the
add-symbol-file command. If that does not work trip subtracting 0x240 from
the load address.

We would need to dump out the UsbAudio.efi file to figure out exactly what
is going on. What distro are you on? Do you have the readpe utility? I’m not
sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look.

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB
myself.
:)
What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There
is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote
9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>
<mailto:afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>
<mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>
<https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>>) like this (from the main
EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb
-device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio
-s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers
and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the
image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump
into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might
be
a
little off on gdb specifics…. Also my terminology may be lldb
centric.

Easy one 1st. When you run on top of a debugger using
CpuBreakpoint()
works
great as the debugger hides its self from you. On x86
CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath the exception 3 is going to get
handled
in
the unexpected exception handler, and that is probably in the CPUD
DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU
acts
a
lot
more like a JTAG hardware debugger than a pure software debugger.
Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the
CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target
for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is
a
handshake that describes the target and what registers are
available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So
this
changing the target definition might confuse the debugger. To be
safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the
debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at
a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst
--
Signed,
Ethin D. Probst


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 2:29 PM, Ethin Probst <harlydavidsen@...> wrote:

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug" at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0  0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1  ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2  _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3  0x000000007fead316 in ?? ()
#4  0x000000007e4f7518 in ?? ()
#5  0x000000007feab5c7 in ?? ()
#6  0x000000007fea3520 in ?? ()
#7  0x0000000101000000 in ?? ()
#8  0x0000000000000030 in ?? ()
#9  0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2   GCC inline implementation of BaseLib processor specific functions.
3
4   Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR>
5   Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
6   SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
 Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug

OK that is interesting…. +576 -> 0x240 witch is about the size of the PE/COFF header. 

For mach-O (macOS executables) we have to link at 0x240 to make space for the PE/COFF header in memory….

So the PE/COFF header starts at 0x7e4b8000 it is likely the text section starts at 0x7e4b8240? So try adding 0x240 to the load address on the add-symbol-file command. If that does not work trip subtracting 0x240 from the load address. 

We would need to dump out the UsbAudio.efi file to figure out exactly what is going on. What distro are you on? Do you have the readpe utility? I’m not sure what you can dump with objcopy?

Can you mail me a copy of UsbAudio.efi off list? I can take a quick look. 

Thanks,

Andrew Fish

The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself.
:)

What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>
<mailto:afish@... <mailto:afish@...>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...
<mailto:harlydavidsen@...>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be
a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath  the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts
a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst







-- 
Signed,
Ethin D. Probst


Re: [edk2-platforms][PATCH] IpmiFeaturePkg : Rename IPMI Macro and Structure Defintions

Oram, Isaac W
 

Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>

-----Original Message-----
From: manickavasakam karpagavinayagam <manickavasakamk@ami.com>
Sent: Friday, June 11, 2021 2:52 PM
To: devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Felixp@ami.com; DOPPALAPUDI, HARIKRISHNA <harikrishnad@ami.com>; Jha, Manish <manishj@ami.com>; Bobroff, Zachary <zacharyb@ami.com>; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@ami.com>; gaoliming@byosoft.com.cn
Subject: [edk2-platforms][PATCH] IpmiFeaturePkg : Rename IPMI Macro and Structure Defintions

Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE
---
.../IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
index 1e0c132508..d788b48867 100644
--- a/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
+++ b/Features/Intel/OutOfBandManagement/IpmiFeaturePkg/GenericIpmi/Dxe/IpmiInit.c
@@ -242,7 +242,7 @@ Returns:
EFI_STATUS Status;

UINT32 DataSize;

SM_CTRL_INFO *pBmcInfo;

- EFI_IPMI_MSG_GET_BMC_EXEC_RSP *pBmcExecContext;

+ IPMI_MSG_GET_BMC_EXEC_RSP *pBmcExecContext;

UINT32 Retries;

#ifdef FAST_VIDEO_SUPPORT

EFI_VIDEOPRINT_PROTOCOL *VideoPrintProtocol;

@@ -301,14 +301,14 @@ Returns:
Status = IpmiSendCommand (

&IpmiInstance->IpmiTransport,

IPMI_NETFN_FIRMWARE, 0,

- EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT,

+ IPMI_GET_BMC_EXECUTION_CONTEXT,

NULL, 0,

IpmiInstance->TempData, &DataSize

);



- pBmcExecContext = (EFI_IPMI_MSG_GET_BMC_EXEC_RSP*)&IpmiInstance->TempData[0];

+ pBmcExecContext = (IPMI_MSG_GET_BMC_EXEC_RSP*)&IpmiInstance->TempData[0];

DEBUG ((DEBUG_INFO, "[IPMI] Operational status of BMC: 0x%x\n", pBmcExecContext->CurrentExecutionContext));

- if ((pBmcExecContext->CurrentExecutionContext == EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE) &&

+ if ((pBmcExecContext->CurrentExecutionContext == IPMI_BMC_IN_FORCED_UPDATE_MODE) &&

!EFI_ERROR (Status)) {

DEBUG ((DEBUG_ERROR, "[IPMI] BMC in Forced Update mode, skip waiting for BMC_READY.\n"));

IpmiInstance->BmcStatus = BMC_UPDATE_IN_PROGRESS;

--
2.25.0.windows.1


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


Re: [edk2][PATCH V1] MdePkg : Add IPMI Macro and Structure Defintions to resolve the IPMI build error

Oram, Isaac W
 

Reviewed-by: Isaac Oram <isaac.w.oram@intel.com>

-----Original Message-----
From: manickavasakam karpagavinayagam <manickavasakamk@ami.com>
Sent: Friday, June 11, 2021 2:50 PM
To: devel@edk2.groups.io
Cc: Oram, Isaac W <isaac.w.oram@intel.com>; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Felixp@ami.com; DOPPALAPUDI, HARIKRISHNA <harikrishnad@ami.com>; Jha, Manish <manishj@ami.com>; Bobroff, Zachary <zacharyb@ami.com>; KARPAGAVINAYAGAM, MANICKAVASAKAM <manickavasakamk@ami.com>; gaoliming@byosoft.com.cn
Subject: [edk2][PATCH V1] MdePkg : Add IPMI Macro and Structure Defintions to resolve the IPMI build error

Build error reported for missing structures IPMI_SET_BOOT_OPTIONS_RESPONSE, EFI_IPMI_MSG_GET_BMC_EXEC_RSP and macros EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FULL_RUNTIME/EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE
when using edk2-platforms\Features\Intel\OutOfBandManagement\IpmiFeaturePkg

MdePkg : Rename IPMI Macro and Structure Defintions

Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
IPMI_BMC_IN_FORCED_UPDATE_MODE
---

Notes:
V1 :
- Rename the EFI_IPMI_MSG_GET_BMC_EXEC_RSPB, EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
- EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE to IPMI_MSG_GET_BMC_EXEC_RSPB,IPMI_GET_BMC_EXECUTION_CONTEXT
- IPMI_BMC_IN_FORCED_UPDATE_MODE

0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch | 61 ++++++++++++++++++++
MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h | 4 ++
MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h | 18 ++++++
3 files changed, 83 insertions(+)

diff --git a/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch b/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch
new file mode 100644
index 0000000000..16d149e2d8
--- /dev/null
+++ b/0001-MdePkg-Add-IPMI-Macro-and-Structure-Defintions-to-re.patch
@@ -0,0 +1,61 @@
+From c5e221cfe5d815883f39b71667b6e8f644a27390 Mon Sep 17 00:00:00 2001
+From: manickavasakam karpagavinayagam <manickavasakamk@ami.com>
+Date: Thu, 10 Jun 2021 14:59:22 -0400
+Subject: [edk2][PATCH] MdePkg : Add IPMI Macro and Structure Defintions
+to resolve the IPMI build error
+
+Build error reported for missing structures
+IPMI_SET_BOOT_OPTIONS_RESPONSE, EFI_IPMI_MSG_GET_BMC_EXEC_RSP and
+macros EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
+EFI_FIRMWARE_BMC_IN_FULL_RUNTIME/EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE
+when using
+edk2-platforms\Features\Intel\OutOfBandManagement\IpmiFeaturePkg
+---
+ MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h | 4 ++++
+MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h | 19
++++++++++++++++++++
+ 2 files changed, 23 insertions(+)
+
+diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+index 79db55523d..d7cdd3a865 100644
+--- a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
++++ b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+@@ -186,6 +186,10 @@ typedef struct {
+ UINT8 ParameterData[0];
+ } IPMI_SET_BOOT_OPTIONS_REQUEST;
+
++typedef struct {
++ UINT8 CompletionCode:8;
++} IPMI_SET_BOOT_OPTIONS_RESPONSE;
++
+ //
+ // Definitions for Get System Boot options command // diff --git
+a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+index 2d892dbd5a..1c692cc792 100644
+--- a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
++++ b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+@@ -17,4 +17,23 @@
+ // All Firmware commands and their structure definitions to follow
+here //
+
++/*----------------------------------------------------------------------------------------
++ Definitions for Get BMC Execution Context
++----------------------------------------------------------------------
++------------------*/ #define EFI_FIRMWARE_GET_BMC_EXECUTION_CONTEXT
++0x23
++
++//
++// Constants and Structure definitions for "Get Device ID" command to
++follow here // typedef struct {
++ UINT8 CurrentExecutionContext;
++ UINT8 PartitionPointer;
++} EFI_IPMI_MSG_GET_BMC_EXEC_RSP;
++
++//
++// Current Execution Context responses //
++#define EFI_FIRMWARE_BMC_IN_FULL_RUNTIME 0x10
++#define EFI_FIRMWARE_BMC_IN_FORCED_UPDATE_MODE 0x11
++
+ #endif
+--
+2.25.0.windows.1
+
diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
index 79db55523d..d7cdd3a865 100644
--- a/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnChassis.h
@@ -186,6 +186,10 @@ typedef struct {
UINT8 ParameterData[0]; } IPMI_SET_BOOT_OPTIONS_REQUEST; +typedef struct {+ UINT8 CompletionCode:8;+} IPMI_SET_BOOT_OPTIONS_RESPONSE;+ // // Definitions for Get System Boot options command //diff --git a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
index 2d892dbd5a..c4cbe2349b 100644
--- a/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
+++ b/MdePkg/Include/IndustryStandard/IpmiNetFnFirmware.h
@@ -17,4 +17,22 @@
// All Firmware commands and their structure definitions to follow here // +// ----------------------------------------------------------------------------------------+// Definitions for Get BMC Execution Context+// ----------------------------------------------------------------------------------------+#define IPMI_GET_BMC_EXECUTION_CONTEXT 0x23++//+// Constants and Structure definitions for "Get Device ID" command to follow here+//+typedef struct {+ UINT8 CurrentExecutionContext;+ UINT8 PartitionPointer;+} IPMI_MSG_GET_BMC_EXEC_RSP;++//+// Current Execution Context responses+//+#define IPMI_BMC_IN_FORCED_UPDATE_MODE 0x11+ #endif--
2.25.0.windows.1


Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


Re: [PATCH v1 3/5] MdeModulePkg: MemoryProfileInfo: Updated MessageLength calculation

Kun Qin
 

Hi Hao,

Thanks for pointing out the missing place. Will update this accordingly.

This patch series needs a PI spec update, I thought I should mark all changes with BZ#### before the spec update is taken. But I can drop them for the next patch version.

Regards,
Kun

On 06/11/2021 00:46, Wu, Hao A wrote:
-----Original Message-----
From: Kun Qin <kuqin12@gmail.com>
Sent: Thursday, June 10, 2021 9:43 AM
To: devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>
Subject: [PATCH v1 3/5] MdeModulePkg: MemoryProfileInfo: Updated
MessageLength calculation

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3398

This change replaced the calculation of communication buffer size from
explicitly adding the size of each member with the OFFSET macro function.
This will make the structure field defition change transparent to consumers.
I think there is one missing place in function GetSmramProfileData():
MinimalSizeNeeded = sizeof (EFI_GUID) +
sizeof (UINTN) +
MAX (sizeof (SMRAM_PROFILE_PARAMETER_GET_PROFILE_INFO),
MAX (sizeof (SMRAM_PROFILE_PARAMETER_GET_PROFILE_DATA_BY_OFFSET),
sizeof (SMRAM_PROFILE_PARAMETER_RECORDING_STATE)));
More inline comments below:


Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
---
MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c | 20
+++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)

diff --git
a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
index 191c31068545..39ed8b2e0484 100644
--- a/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
+++
b/MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.c
@@ -1190,7 +1190,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_DISABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
Please help to drop the explicit mention of BZ3398 in the comment.
How about using:
//
// The CommHeader->MessageLength contains a definitive value, thus UINTN cast is safe here.
//
There are 4 more similar cases below.
Best Regards,
Hao Wu

+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Status = SmmCommunication->Communicate (SmmCommunication,
CommBuffer, &CommSize);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "SmramProfile: SmmCommunication - %r\n",
Status)); @@ -1213,7 +1215,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_DISABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
SmmCommunication->Communicate (SmmCommunication, CommBuffer,
&CommSize);
}

@@ -1230,7 +1234,9 @@ GetSmramProfileData (
CommGetProfileInfo->Header.ReturnStatus = (UINT64)-1;
CommGetProfileInfo->ProfileSize = 0;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Status = SmmCommunication->Communicate (SmmCommunication,
CommBuffer, &CommSize);
ASSERT_EFI_ERROR (Status);

@@ -1261,7 +1267,9 @@ GetSmramProfileData (
CommGetProfileData->Header.DataLength = sizeof
(*CommGetProfileData);
CommGetProfileData->Header.ReturnStatus = (UINT64)-1;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
Buffer = (UINT8 *) CommHeader + CommSize;
Size -= CommSize;

@@ -1320,7 +1328,9 @@ GetSmramProfileData (
CommRecordingState->Header.ReturnStatus = (UINT64)-1;
CommRecordingState->RecordingState =
MEMORY_PROFILE_RECORDING_ENABLE;

- CommSize = sizeof (EFI_GUID) + sizeof (UINTN) + CommHeader-
MessageLength;
+ // BZ3398: Make MessageLength the same size in
EFI_MM_COMMUNICATE_HEADER for both IA32 and X64.
+ // The CommHeader->MessageLength contains a definitive value, thus
UINTN cast is safe here.
+ CommSize = OFFSET_OF(EFI_SMM_COMMUNICATE_HEADER, Data) +
+ (UINTN)CommHeader->MessageLength;
SmmCommunication->Communicate (SmmCommunication, CommBuffer,
&CommSize);
}

--
2.31.1.windows.1


Re: Help with debugging

Ethin Probst
 

Initial connection and loading symbols:
Remote debugging using :1234
0x000000007e4b9517 in ?? ()
add symbol table from file "Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug" at
.text_addr = 0x7e4b8000
Reading symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Expanding full symbols from Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug...
Backtrace:
#0 0x000000007e4b9517 in UefiMain (st=0x7f9ee018,
imageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/MdeModulePkg/Application/UsbAudio/UsbAudio.c:72
#1 ProcessModuleEntryPointList (SystemTable=0x7f9ee018,
ImageHandle=0x7e4f7518) at
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/MdeModulePkg/Application/UsbAudio/UsbAudio/DEBUG/AutoGen.c:300
#2 _ModuleEntryPoint (ImageHandle=0x7e4f7518, SystemTable=0x7f9ee018)
at /home/ethin/source/edk/edk2/MdePkg/Library/UefiApplicationEntryPoint/ApplicationEntryPoint.c:59
#3 0x000000007fead316 in ?? ()
#4 0x000000007e4f7518 in ?? ()
#5 0x000000007feab5c7 in ?? ()
#6 0x000000007fea3520 in ?? ()
#7 0x0000000101000000 in ?? ()
#8 0x0000000000000030 in ?? ()
#9 0x000000007e4f6018 in ?? ()
#10 0x000000007e60a918 in ?? ()
#11 0x000000000000011d in ?? ()
#12 0x000000007fea3528 in ?? ()
#13 0x000000007e4f7818 in ?? ()
#14 0x000000007e4f7c98 in ?? ()
#15 0x000000007fea3538 in ?? ()
#16 0x000000007e3abfca in ?? ()
#17 0x000000007e4f7418 in ?? ()
#18 0x000000007fea3528 in ?? ()
#19 0x0000000000000000 in ?? ()
Source-code listing:
1 /** @file
2 GCC inline implementation of BaseLib processor specific functions.
3
4 Copyright (c) 2006 - 2020, Intel Corporation. All rights reserved.<BR>
5 Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
6 SPDX-License-Identifier: BSD-2-Clause-Patent
7
8 **/
9
10
Attempt to use "next":
72 } else if (interfaceDescriptor.InterfaceClass == 0x01 &&
interfaceDescriptor.InterfaceSubClass == 0x03) {
(This is my code but it continuously prints this same line over and
over every time "next" is used.)
Attempt to use "print Index":
No symbol "Index" in current context.
info local:
UsbIo = 0x0
interfaceDescriptor = {Length = 0 '\000', DescriptorType = 8 '\b',
InterfaceNumber = 1 '\001', AlternateSetting = 0 '\000', NumEndpoints
= 0 '\000', InterfaceClass = 0 '\000', InterfaceSubClass = 0 '\000',
InterfaceProtocol = 0 '\000',
Interface = 0 '\000'}
i = 2118887920
numHandles = 264
handles = 0x4
status = <optimized out>
info symbol 0x0007E4B9440:
_ModuleEntryPoint + 576 in section .text of
/home/ethin/source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles available. And GDB is making it look like
its skipping all of that.

On 6/11/21, Andrew Fish <afish@apple.com> wrote:


On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself.
:)
What do you get from the following gdb commands?
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is
no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
<mailto:afish@apple.com <mailto:afish@apple.com>>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@gmail.com
<mailto:harlydavidsen@gmail.com>>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run
<https://github.com/Richard-W/uefi-run>) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at
this
point:
1. Either I get the wrong debug information (I get source code but
the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just
sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys
have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be
a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint()
is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t
have
a
debugger hooked in underneath the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers
it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts
a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the
symbols.
The
reason for me suggesting this flow is the debugger has a flexible
concept
of
what the target is. If you load symbols that will create a target for
a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available.
I
seem
to remember QEMU exports some of the system registers, like the
control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe
I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you
need
to
specify the load address to get the symbols to resolve. One trick I
use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and
it
prints out the load address and offset (you can use the offset
directly).
It
is also a good way to debug why your symbols are not quite loaded at
the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst



--
Signed,
Ethin D. Probst


--
Signed,
Ethin D. Probst


Re: GSOC 2021 EXT4 driver Project

Michael D Kinney
 

Hi Michael,

Thanks for the feedback.

#4 should be clarified as adding a new feature package called Ext4Pkg. Not adding EXT4 to the existing AdvancedFeaturePkg.

Mike

-----Original Message-----
From: Michael Kubacki <mikuback@linux.microsoft.com>
Sent: Friday, June 11, 2021 11:23 AM
To: devel@edk2.groups.io; leif@nuviainc.com; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: pedro.falcato@gmail.com
Subject: Re: [edk2-devel] GSOC 2021 EXT4 driver Project

I had done some of the early work in moving content to
edk2-platforms/Features. Just wanted to add my support for maintaining
this as a vendor neutral feature there.

#4 in the options list is not really what AdvancedFeaturePkg intended
for, there's more details here -
https://github.com/tianocore/edk2-platforms/tree/master/Features/Intel#AdvancedFeaturePkg.

- Michael

On 6/10/2021 1:54 PM, Leif Lindholm wrote:
edk2-platforms/Features/Ext4Pkg sounds good to me too.

/
Leif

On Thu, Jun 10, 2021 at 17:38:17 +0000, Michael D Kinney wrote:
Hi Pedro,

After thinking about this, I think I would prefer Option (4).

The proposed landing zone would be a new Ext4Pkg in the edk2-platforms repository in the Features directory.

edk2-platforms/Features/Intel/Ext4Pkg

All the features in that directory and not specific to Intel. There are other email discussions about moving some of
that content up a level, so an alternative path would be:

edk2-platforms/Features/Ext4Pkg

Best regards,

Mike


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pedro Falcato
Sent: Monday, May 24, 2021 12:27 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] GSOC 2021 EXT4 driver Project

Hi everyone,

Me and my project have been selected for GSoC this year, under Michael Kinney and bret. Thank you for the opportunity
to collaborate with you and improve Tianocore!
If anyone has any questions, please fire away :)
How do I get started? I'd like to find some easier tasks as to start trying out patch submission and generally
programming in a firmware environment.
Also, I've been talking with my mentors and a relevant question to ask the mailing list is: Where should we put the
EXT4 driver?
Michael said there are other filesystems in MdeModulePkg, but it might be getting too big and proposed the following
options:

1) EXT4 in new package in edk2 repo as a peer to FatPkg.
2) EXT4 in edk2 repo in MdeModulePkg
3) EXT4 in edk2-platforms advanced feature package.
4) EXT4 in edk2 advanced feature package

As someone that's still learning how to navigate the project's tree(s), this is a bit over my head and so I'd like your
opinion on the matter.
Also, I would love if someone could point me to some good reading material and/or examples of the package/build system,
as I couldn't find documentation on those
and my previous experiment with Tianocore involved looking at FatPkg and mindlessly copying what it was doing.

Thanks,

Pedro








TianoCore Community Meeting Minutes - June

Soumya Guptha
 

TianoCore Community Meeting

June 10, 2021

 

EVENTS:

  • UEFI Plugfest (update from Dick Wilkins)
  • Plugfest is being planned for early April 2022 in Oregon. Detailed planning of the schedule and logistics will kick off in a few weeks.
  • ICWG is hosting UEFI Virtual Plugfest webinars, if you are interested in presenting, please send your proposals to UEFI plugfest.

 

Google Summer of Code (update from Nate Desimone)

  • Google has announced this year's Summer of Code students. TianoCore is mentoring 7 students this year, which is more than 3 times larger than our previous high of 2 students! The list of projects is available here: https://summerofcode.withgoogle.com/organizations/6376892141142016/
  • Students have started submitting patches. Students need to complete projects by mid-august.
  • Community Action: Provide feedback to students and support them to be successful.

 

Stable Tag updates:

  • EDK2 Stable Tag 202105 has been released. EDK2 Stable Tag 202108 is collecting features.
  • Details here: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
  • Action: Bugzilla needs to be updated with the latest Stable tag info – Mike Kinney will update.
  • From Google summer of code projects, if there are any features impacting EDK2 core, we need to make sure that those features get into the stable tag. Mentors need to work on getting those features in and communicate with Liming Gao. Action: Nate Desimone plans to communicate with the mentors and educate them on the process.

 

Stewards Meeting Download (update from Mike Kinney)

  • Discussed process issue - During beginning soft/hard releases, we need to add a RC1 & RC0 tags when soft and hard freeze are announced to support validation. Lazlo plans to write an RFC on this topic. Once this approves, liming may need to update the documentation.
  • There is some confusion with Roles and Responsibilities (R&R) between maintainers and reviewers around reviewing packet (push label/merge). Reviewers also have push access. But Maintainer is the gate keeper and should approve the final changes to the package. Action for Stewards: We need to update the documentation (development process, who we are and any other wiki pages that are impacted) and clarify the R&R.
  • Enhance support on previous Stable Tags - we will support critical bug fixes and security issues to the most recent Stable Tag.
    • Release process between stable tags is typically 3 months. Today we are operating reactively based on request. We want to have a standard process. If there is a critical issue (such as a security issue)/bug fixes in the subprojects, we want to be more proactive by having a standard operating process to have these propagated into our most recent stable tag.
    • Action: Liming to update the support of Stable Tags to reflect this change.

 

Opens

  • (Open from Nate) NVME 2.0 just got formally published. Most interesting feature to be evaluated is “Zoned name space” feature. Any UEFI spec changes. Action: Evaluate and determine to see if we need to support this feature. What will be our plan for doing this? A topic for Ray Ni’s design meeting. Soumya to communicate with Ray Ni on this topic.
  • Update from Soumya: Puja Pandya moved on to pursue another opportunity. Soumya Guptha will continue to lead TianoCore Community Management.

 

Acknowledgements

Mike Kinney thanked Kevin Davis for doing analysis for UEFI 2.8 specification gaps.

 

 

Regards,

Soumya Guptha

TianoCore Community Manager

 

 

 

 


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 1:48 PM, Ethin Probst <harlydavidsen@...> wrote:

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself. :)

What do you get from the following gdb commands? 
bt
info local
info symbol 0x0007E4B9440

What exactly is gdb showing you?

Thanks,

Andrew Fish


On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@... <mailto:afish@...>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this
point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint() is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have
a
debugger hooked in underneath  the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the symbols.
The
reason for me suggesting this flow is the debugger has a flexible concept
of
what the target is. If you load symbols that will create a target for a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available. I
seem
to remember QEMU exports some of the system registers, like the control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you need
to
specify the load address to get the symbols to resolve. One trick I use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and it
prints out the load address and offset (you can use the offset directly).
It
is also a good way to debug why your symbols are not quite loaded at the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









--
Signed,
Ethin D. Probst







-- 
Signed,
Ethin D. Probst




Re: Help with debugging

Ethin Probst
 

Okay, so I just tried exactly what you told me to do -- use
CpuDeadLoop() and then just modify index to get out of it. Here's what
I do in GDB:
- Load the EFI application and connect via target remote :1234
- type `add-symbol-file Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
0x0007E4B8000` and answer yes when it prompts me to do so.
(0x0007E4B8000 is the image base, the entry point is at
0x0007E4B9440.)
- When I try to print the Index symbol, GDB tells me that it isn't in
the current context.
I feel like I'm missing something. I'm also not the best with GDB myself. :)

On 6/11/21, Andrew Fish <afish@apple.com> wrote:


On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is no
gdb with Xcode, so I have to use lldb for my day job.

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000”
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@gmail.com>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this
point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?
Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint()
works
great as the debugger hides its self from you. On x86 CpuBreakpoint() is
an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have
a
debugger hooked in underneath the exception 3 is going to get handled
in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a
lot
more like a JTAG hardware debugger than a pure software debugger. Also
note
that CpuDeadLoop() is an infinite loop, so you can modify the loop
variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the symbols.
The
reason for me suggesting this flow is the debugger has a flexible concept
of
what the target is. If you load symbols that will create a target for a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available. I
seem
to remember QEMU exports some of the system registers, like the control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked
around
zero. They get loaded into memory and relocated, so that is why you need
to
specify the load address to get the symbols to resolve. One trick I use
is
to load the ELF (or PE/COFF) build output directly into the debugger.
This
lets you poke around the image at the linked address. You can
disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and it
prints out the load address and offset (you can use the offset directly).
It
is also a good way to debug why your symbols are not quite loaded at the
correct address, as you can see what bytes/instructions should be at a
given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst





--
Signed,
Ethin D. Probst


--
Signed,
Ethin D. Probst


Re: Help with debugging

Andrew Fish
 



On Jun 11, 2021, at 11:39 AM, Ethin Probst <harlydavidsen@...> wrote:

Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?


Ethin,

Lldb is the command line debugger that comes with Xcode on Mac. There is no gdb with Xcode, so I have to use lldb for my day job. 

Lldb can speak the gdb remote serial protocol: lldb -o “gdb-remote 9000” 
That assumes you passed `-gdb tcp::9000`to QEMU.

Thanks,

Andrew Fish

On 6/11/21, Andrew Fish <afish@...> wrote:


On Jun 11, 2021, at 10:06 AM, Ethin Probst <harlydavidsen@...>
wrote:

Hey all,

So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.

I'm having a lot of trouble debugging my UEFI app. Here's how I do
things:

- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directory): uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon file:../debug.log -global isa-debugcon.iobase=0x402
-nographic
Or:
uefi-run -b Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd
Build/OvmfX64/DEBUG_GCC5/X64/Shell.efi -- -M q35 -m 24G -usb -device
qemu-xhci -device usb-audio,audiodev=audio -audiodev alsa,id=audio -s
-debugcon stdio -global isa-debugcon.iobase=0x402
- I connect to the remote GDB stub (localhost:1234) and wait until
OVMF gives me the image base. Then I use:
add-symbol-file UsbAudio.debug <image base>
Here's where everything breaks down. One of two things happens at this
point:
1. Either I get the wrong debug information (I get source code but the
image isn't loaded anymore), and resetting the system and placing a
breakpoint (either software or hardware) has no effect; or
2. If I use CpuBreakpoint(), the firmware gives me the registers and
the image base and entry point addresses, and then appears to just sit
there waiting for something. Once I load the symbols using the image
base it gives me, I can't actually do anything in the debugger; I
can't list code because I get "1 in <artificial>", I can't jump into
my code without triggering a general protection exception or not
actually causing anything to happen... You get the idea.

So I'm really, really confused on what's going wrong. Do you guys have
any advice?

Ethin,

Caveat emptor as I use lldb for my daily driver debugger so I might be a
little off on gdb specifics…. Also my terminology may be lldb centric.

Easy one 1st. When you run on top of a debugger using CpuBreakpoint() works
great as the debugger hides its self from you. On x86 CpuBreakpoint() is an
INT 3h instruction (0xCC) and it causes an exception 3. If you don’t have a
debugger hooked in underneath  the exception 3 is going to get handled in
the unexpected exception handler, and that is probably in the CPUD DXE
driver or DXE Core or some such. So you are going to end up with the
PC/IP/RIP in the wrong driver. A lot of times for hardware debuggers it
works better to use CpuDeadLoop(). The gdb-remote stub from QEMU acts a lot
more like a JTAG hardware debugger than a pure software debugger. Also note
that CpuDeadLoop() is an infinite loop, so you can modify the loop variable
with the debugger to continue.

I’d suggest a work flow of run your App/Driver, hit the CpuDeadLoop(),
attach gdb. Now after you have the target established load the symbols. The
reason for me suggesting this flow is the debugger has a flexible concept of
what the target is. If you load symbols that will create a target for a
stock x86-64 image. When you connect to the QEMU gdb-remote there is a
handshake that describes the target and what registers are available. I seem
to remember QEMU exports some of the system registers, like the control
registers, so it is an extended version of the x86-64 target. So this
changing the target definition might confuse the debugger. To be safe I
always connect 1st and then load symbols.

The EFI images are PE/COFF relocatable executables that are linked around
zero. They get loaded into memory and relocated, so that is why you need to
specify the load address to get the symbols to resolve. One trick I use is
to load the ELF (or PE/COFF) build output directly into the debugger. This
lets you poke around the image at the linked address. You can disassemble
the functions to see what they look like, obviously you can read any
variables. This can be useful if you get the unhandled exception and it
prints out the load address and offset (you can use the offset directly). It
is also a good way to debug why your symbols are not quite loaded at the
correct address, as you can see what bytes/instructions should be at a given
address.

Thanks,

Andrew Fish


--
Signed,
Ethin D. Probst









-- 
Signed,
Ethin D. Probst



7681 - 7700 of 84031