On Apr 9, 2013, at 2:13 PM, Duane Voth <dua...@gmail.com> wrote:
> previous thread was: [edk2] OVMF networking revisited
> Spliting off this gdb+qemu+ovmf debugging discussion.
> Versions:
> qemu-kvm 1.2.0
> gdb 7.5.1
> OVMF X64 built on Linux with GCC 4.6
>
> On Tue, Apr 9, 2013 at 12:27 AM, Joe Vernaci <jvern...@gmail.com> wrote:
> ...
> The error you are seeing means gdb does not have a type for EFI_SYSTEM_TABLE
> so the file provided when you ran the command 'reload-uefi
> /path/to/GdbSyms.dll' either was not there or did not have a symbol for
> EFI_SYSTEM_TABLE. You can confirm this by running 'info types
> EFI_SYSTEM_TABLE_POINTER' after you have run 'reload-uefi ...' It should
> tell you there is nothing matching this type.
>
> Here is Andrei's blog documenting GdbSyms:
> http://osdevnotes.blogspot.com/2011/05/gdb-scripting-example-reloading-symbols.html
>
> Let's get more concrete and use actual command lines:
>
> term1: $ qemu-system-x86_64 -m 1024 -bios OVMF.fd -S -s -monitor stdio
>
> term2: $ cd edk2/OvmfPkg
> term2: $ gdb
> term2: (gdb) target remote :1234
> term2: (gdb) source ../../andreiw-wip/uefi/DebugPkg/Scripts/gdb_uefi.py
> term2: (gdb) reload-uefi -o
> ../Build/AppPkg/DEBUG_GCC46/X64/AppPkg/Applications/GdbSyms/GdbSyms/DEBUG/GdbSyms.dll
> term2: Python Exception <class 'gdb.error'> No type named
> EFI_SYSTEM_TABLE_POINTER
> term2:
>
> As I understand his site, the above is how we're supposed to load and use
> GdbSyms. I assumed that 2 years ago (when Andrei last used GdbSyms) that no
> other command lines were needed and that over the last couple years only
> symbol names might have changed.
>
I don't think the symbols have changed. EFI_SYSTEM_TABLE_POINTER was in the EFI
spec a long time ago, and the types for cracking PE/COFF have not changed for
years now.
Given you don't know if the symbols are out of date that implies you are using
a binary GdbSyms.dll? Maybe there is some issues with your version of gdb and
the binary. I'd recommend you rebuilt GdbSyms from source and try again.
>
> An alternative approach that has provided some fruit is that I also have
> .debug files in my edk2/Build directory which load into gdb. However, since
> this is ROM/bootstrap code, the offsets need to be set manually. (without
> using GdbSyms) I've managed to get this far using this alternate approach:
>
> term1: $ qemu-system-x86_64 -m 1024 -bios OVMF.fd -S -s -monitor stdio
>
> term2: $ cd edk2/OvmfPkg
> term2: $ gdb
> term2: (gdb) target remote :1234
> term2: (gdb) add-symbol-file ../Build/OvmfX64/DEBUG_GCC46/X64/SecMain.debug
> 0xfffcc2c4
> term2: add symbol table from file
> "../Build/OvmfX64/DEBUG_GCC46/X64/SecMain.debug" at
> term2: .text_addr = 0xfffcc2c4
> term2: (y or n) y
> term2: Reading symbols from
> /home/duanev/efi/edk2/Build/OvmfX64/DEBUG_GCC46/X64/SecMain.debug...done.
> term2: (gdb)
> term2: (gdb) info address FindMainFv
> term2: Symbol "FindMainFv" is a function at address 0xfffcc2db.
> term2: (gdb) info address EFI_SYSTEM_TABLE
> term2: No symbol "EFI_SYSTEM_TABLE" in current context.
> term2: (gdb) info type EFI_SYSTEM_TABLE_POINTER
> term2: All types matching regular expression "EFI_SYSTEM_TABLE_POINTER":
> term2: (gdb)
>
> where 0xfffcc2c4 was determined empirically. At this point all the text
> addresses line up correctly and single stepping isn't as barren a prospect,
> however computing the load offset for the symbol table is I believe exactly
> what Andrei managed to automate.
>
>
> His script like mine use the system table pointer which as I said above is
> only valid after DxeMain.efi is loaded. After a quick grep it looks like
> AcpiTimerLibConstructor is only called from Dxe files so this should be ok.
>
>
> Ovmf appears to be "a collection" of .efi files (again each with some new
> offset). SecMain.debug (aka. SecMain.efi) seems to provide all the symbols I
> need for my ACPI debugging, and that includes several of the modules in the
> ovmf collection, but this is all a bit kludgy. I hope there is something I'm
> missing...
>
>
> Also you can read the i/o ports from qemu's monitor is the 'i' command or
> from gdb with the 'monitor i' command.
>
> Thanks for pointing this out. Interestingly, though, all my gdb 'monitor'
> commands return blank lines with the exact count of the number of actual
> lines they should have printed. :) I'll use the qemu command line for now...
>
>
> ------------------------------------------------------------------------------
> 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
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
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
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
