My next suggestion is to use the -y and -Y flags to the build.exe command to
generate a report and review the PCD value used to see if the they are being
set to the expected value of 0xB000 and not 0x400.
The next step after that is to review the AutoGen.h files in the build output
directory for the modules that are getting the incorrect 0x400 values in the
OBJs to verify that the AutoGen.h has 0x400.
If you explicitly set the PCD value in your DSC file to different values, you
should see that value in the -Y report file and the AutoGen.h files. If not,
then something odd happening with build tools.
Mike
From: Duane Voth [mailto:[email protected]]
Sent: Thursday, April 11, 2013 7:49 AM
To: [email protected]
Subject: Re: [edk2] OVMF networking revisited
How is [it] possible [that AcpiTimerLibConstructor() runs in 32bit mode] ?
AFAIR you have an X64 build.
Laszlo, I'm just reporting what gdb is demanding: "set arch i386" for the
constructor (which displays 32bit flat 0xfffcxxxx addresses), and "set arch
i386:x86-64" for the hang location (which displays 64bit flat 0x3e55xxxx
addresses). Since OVMF is a boot rom it has to bring the cpu up from i8086 to
i386 to x86-64 modes and apparently various parts of the code run in different
modes.
find Build -type f -name '*.obj' -print0 \
| xargs -0 -r -- objdump -d -- >~/tmp/disasm
less ~/tmp/disasm
Then search for \$0x408, and scroll up for the function name. In my
build there are three functions with this constant:
- UnicodeStrToAsciiStr
- LibPatchPcdSetPtr
- EhcAsyncInterruptTransfer
None of which seem relevant.
Yes, that's what I'm finding as well. And looking at AcpiTimerLib.obj via
objdump tells me that the hang code is not from AcpiTimerLib at all.
Is there any chance you have pulled in the TscTimerLib from the PerformancePkg
into the X64 part of your build?
Michael, well, there is no TscTimerLib.obj in Build/OvmfX64/DEBUG_GCC46/X64
(and in fact no where in the Build directory at all), I've never built the
PerformancePkg.
Curiouser and curiouser ... even the .efi files, scanned with
find Build -type f -name '*.efi' -print0 | xargs -0 -r -- objdump -d -- | grep
'$0x408,'
return *only* mov $0x408,%edx where clearly the executing code includes
mov $0x408,%ecx ! Where is this bit of rogue code coming from??
What prevents you from setting DEBUG_VERBOSE
With DEBUG_VERBOSE on and -debugcon file:debug.log -global
isa-debugcon.iobase=0x402 added to the qemu command line, debug.log remains
empty. I've never seen any debug output from this flag nor via -debugcon. My
OVMF build line is:
$ build -D SOURCE_DEBUG_ENABLE -D FD_SIZE_2MB -D DEBUG_ON_SERIAL_PORT -p
OvmfPkg/OvmfPkgX64.dsc -a X64 -t GCC46
(when I add other debug code and rebuild, I do see the changes in gdb so I'm
not missing something obvious)
Yes it is very easy to rebuild OVMF and try it out with qemu+gdb which is why
I'm pushing to get debug with symbols working -- my other avenue (an In circuit
Test Probe on real hardware will be laborious).
Duane
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
