Thanks for making a new title it'll be easier to track...
Andrew is right those have not changed in quite a long time and even if
they did since GdbSyms builds against current headers it won't matter.
Gcc builds the .dll files as a self contained binary which is passed
through GenFw which if needed will convert elf binaries to pe/coff (efi)
binaries. But the mingw cross compiler (UNIXGCC toolchain) is capable of
producing pe/coff on it's own for use in Windows. So to strip and preserve
the debug symbols in the gcc produced pe/coff .dll files objcopy is used to
place them in a .debug file and use .gnu_debuglink to point the .dll to
that file. GenFw then makes a it's own link from the .efi to the .dll.
The .gnu_debuglink probably isn't needed anymore but it was used when GenFw
wasn't as capable as it is now.
Since I don't have GdbSyms I'll be using DxeCore.* since I know it has all
of the symbols you need. Also I'm using Ia32 since I seem to be having
issues with gdb-multiarch on x86_64.
$cd edk2/Build/OvmfIa32/DEBUG_GCC47/IA32$
$ objdump -s -j .debug DxeCore.efi
DxeCore.efi: file format pei-i386
Contents of section .debug:
288e0 00000000 00000000 00000000 02000000 ................
288f0 7d000000 fc880200 fc880200 4e423130 }...........NB10
28900 00000000 00000000 00000000 2f686f6d ............/hom
28910 652f6a6f 65766578 742f6769 742f6375 e/joevext/git/cu
28920 7474792f 65646b32 2f427569 6c642f4f tty/edk2/Build/O
28930 766d6649 6133322f 44454255 475f4743 vmfIa32/DEBUG_GC
28940 4334372f 49413332 2f4d6465 4d6f6475 C47/IA32/MdeModu
28950 6c65506b 672f436f 72652f44 78652f44 lePkg/Core/Dxe/D
28960 78654d61 696e2f44 45425547 2f447865 xeMain/DEBUG/Dxe
28970 436f7265 2e646c6c 00000000 00000000 Core.dll........
** This is the link created by GenFw when converting the elf .dll to
pe/coff .efi. This would be discovered on the running target by the python
scripts
$cd MdeModulePkg/Core/Dxe/DxeMain/DEBUG
$ objdump -s -j .gnu_debuglink DxeCore.dll
DxeCore.dll: file format elf32-i386
Contents of section .gnu_debuglink:
0000 44786543 6f72652e 64656275 67000000 DxeCore.debug...
0010 467942d7 FyB.
** This is the link created by objcopy --add-gnu-debuglink. This would be
followed automatically by gdb if DxeCore.dll was loaded with
[add-]symbol-file
$ objdump -Wi DxeCore.debug | grep EFI_SYSTEM_TABLE_POINTER
<df4a> DW_AT_name : (indirect string, offset: 0x44c5):
EFI_SYSTEM_TABLE_POINTER
** There's the symbol you need. Of course you should be doing this with
the GdbSyms.dll and as long as everything is there the problem is not the
symbol files. So for my case I this works and should be sort of what the
script is doing up to the type error you get.
$gdb-multiarch
(gdb) symbol-file DxeCore.dll
Reading symbols from
/home/joevext/git/cutty/edk2/Build/OvmfIa32/DEBUG_GCC47/IA32/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll...Reading
symbols from
/home/joevext/git/cutty/edk2/Build/OvmfIa32/DEBUG_GCC47/IA32/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.debug...done.
done.
(gdb) python print gdb.lookup_type('EFI_SYSTEM_TABLE_POINTER')
EFI_SYSTEM_TABLE_POINTER
(gdb)
I'm guessing what ever is going wrong may be getting buried in his
scripts...
Also some of my gdb monitor commands don't work either ... never could
figure out why so at least I'm not the only one. I see the packets going
over the remote just nothing ever happens.
On Tue, Apr 9, 2013 at 5:45 PM, Andrew Fish <af...@apple.com> wrote:
>
> 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
>
>
------------------------------------------------------------------------------
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
