On 04/11/13 00:14, Duane Voth wrote:
> Ok, while qemu emulation is not stopped, periodic samples of 0xb008
> (using the qemu cmd "i/w 0xb008") do indeed return running timer-like
> values.
>
> AcpiTimerLibConstructor() runs in 32bit mode
How is that possible? AFAIR you have an X64 build.
> and uses 0xb0nn values, but
> at the point of my hang the cpu is in 64bit mode and is reading from
> 0x0408 instead of 0xb008. Disassembly shows that 0x0408 is a constant
> compiled into the source:
>
> 0x3e5576e2: push %rbp
> 0x3e5576e3: mov %rsp,%rbp
> 0x3e5576e6: sub $0x20,%rsp
> 0x3e5576ea: mov $0x408,%ecx
> 0x3e5576ef: movabs $0x3e5579fa,%rax
> 0x3e5576f9: callq *%rax
> 0x3e5576fb: leaveq
> 0x3e5576fc: retq
Perhaps:
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.
>
>
>
>
> (this next part of the conversation will move to the new gdb symbol
> debug thread - but I wanted Laszlo to see this last comment/question)
>
>
> You need the debug symbols for the qemu binary. Your distro may
> provide them in a separate package, or not at all. In the latter
> case you should rebuild from source (with --enable-debug), or
> rebuild your distro's package with debug symbols enabled.
>
>
> gdb needs qemu *symbols* in order for breakpoints to work? I thought
> the gdbserver built into qemu would simply provide the proper API over
> the remote link. I can however see why a released version of qemu would
> not have --enable-debug turned on (disabling breakpointing).
We're mixing up two things here.
(1) Qemu has some gdbserver-like stuff ("backend") built-in, which
allows you to debug the guest. For this you probably need guest symbols
in the gdb frontend.
I have very little experience with this facility (no idea about
breakpoint support, for example), as I've found DEBUG() messages to work
(almost) universally in edk2 -- we have the source and it's very quick
to recompile edk2 & reboot the guest with it. (Doing the same with a
bare-metal kernel or hypervisor is much more time consuming.) The
messages can go to the qemu debug port (default) or emulated serial port
(build option).
What prevents you from
- setting DEBUG_VERBOSE
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2382/focus=2385>,
- capturing the debug port traffic in a file
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2382/focus=2413>,
- and narrowing down from there with new DEBUG() calls?
(Note that you
- either have to pass *both* "-debugcon file:/tmp/debug.log" and
"-global isa-debugcon.iobase=0x402",
- or build with "-D DEBUG_ON_SERIAL_PORT" and capture the serial port.)
(2) The symbols I mentioned belong to the qemu-system-x86_64 binary on
the host system. That is, the emulator. Sometimes it's useful to debug
the emulator when the guest is doing something weird. When I had
referred to pm_io_space_update()
<http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2382/focus=2495>,
I'd had this in mind. (At that point it wasn't clear whether
AcpiTimerLibConstructor() was executing OK.)
Laszlo
------------------------------------------------------------------------------
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
