Debugging Ovmf with GDB: No symbol is recognized

Debugging Ovmf with GDB: No symbol is recognized

[koenig_regina]

[-- Attachment #1: Type: text/plain, Size: 6028 bytes --]

Hi, I am trying to debug OVMF as suggested in https://retrage.github.io/2019/12/05/debugging-ovmf-en.html.
Almost every step seems to work fine.

I built edk2 as follow:
------------------------------
$ git clone git@github.com:tianocore/edk2.git \
$ cd edk2$ git submodule update --init --recursive
$ make -C BaseTools
$ source ./edksetup.sh
$ build -p OvmfPkg/OvmfPkgX64.dsc -b DEBUG -a X64 -t GCC5

My Makefile looks like this:
--------------------------------------
#!/usr/bin/env make

SHELL=/bin/bash

LOG=debug.log
OVMFBASE=edk2/Build/OvmfX64/DEBUG_GCC5/
OVMFCODE=$(OVMFBASE)/FV/OVMF_CODE.fd
OVMFVARS=$(OVMFBASE)/FV/OVMF_VARS.fd
QEMU=qemu-system-x86_64
QEMUFLAGS=-drive format=raw,file=fat:rw:image \
-drive if=pflash,format=raw,readonly,file=$(OVMFCODE) \
-drive if=pflash,format=raw,file=$(OVMFVARS) \
-debugcon file:$(LOG) -global isa-debugcon.iobase=0x402 \
-serial stdio \
-nographic \
-nodefaults

run:
$(QEMU) $(QEMUFLAGS)

debug:
$(QEMU) $(QEMUFLAGS) -s -S

.PHONY: run debug

As first step, I let it run to get a debug.log where all the loading addresses are stored:
---------------------------------------------------------------------------------------------------------------------
$ make run

Here an example of the information stored in debug.log:
--------------------------------------------------------------------------------
$ less debug.log
...
The 0th FV start address is 0x0000082000
...
Loading PEIM at 0x0000082BFC0
Entry Point = 0x0000082F40A PcdPeim.efi
...

To extract the .text section from *.efi binaries, I need peinfo:
-----------------------------------------------------------------------------------------
$ git clone git@github.com:retrage/peinfo.git
$ cd peinfo
$ make

I use peinfo in a bash script (gen_symbol_offset.sh) to get the symbol addresses:
................................................................................................
#!/bin/bash

LOG="debug.log"
BUILD="edk2/Build/OvmfX64/DEBUG_GCC5/X64"
PEINFO="peinfo/peinfo"

cat ${LOG} | grep Loading | grep -i efi | while read LINE; do
BASE="`echo ${LINE} | cut -d " " -f4`"
NAME="`echo ${LINE} | cut -d " " -f6 | tr -d "[:cntrl:]"`"
ADDR="`${PEINFO} ${BUILD}/${NAME} \
| grep -A 5 text | grep VirtualAddress | cut -d " " -f2`"
TEXT="`python -c "print(hex(${BASE} + ${ADDR}))"`"
SYMS="`echo ${NAME} | sed -e "s/\.efi/\.debug/g"`"
echo "add-symbol-file ${BUILD}/${SYMS} ${TEXT}"
done

...and create a script for gdb to add the symbol files:
-----------------------------------------------------------------------------
$ bash gen_symbol_offsets.sh > gdbscript
$ cat gdb
...
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/PcdPeim.debug 0x82c380
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/ReportStatusCodeRouterPei.debug 0x831080
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/StatusCodeHandlerPei.debug 0x833100
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/PlatformPei.debug 0x835100
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/PeiCore.debug 0x7ee8240
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/DxeIpl.debug 0x7ee3240
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/S3Resume2Pei.debug 0x7edf240
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/CpuMpPei.debug 0x7ed6240
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/DxeCore.debug 0x7ea8240
add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/DevicePathDxe.debug 0x7b8f240
...

Second step is to run it again with -s -S flags, Qemu waits for connection
----------------------------------------------------------------
$ make debug

In a second Terminal I type:
-------------------------------------------------
$ gdb
(gdb) source gdbscript
....
add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/UsbBusDxe.debug" at
.text_addr = 0x6c85240
add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/UsbKbDxe.debug" at
.text_addr = 0x6cb3240
add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/UsbMassStorageDxe.debug" at
.text_addr = 0x6c6d240
add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/QemuVideoDxe.debug" at
.text_addr = 0x6c66240
add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/VirtioGpuDxe.debug" at
.text_addr = 0x6c60240
add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/Shell.debug" at
.text_addr = 0x64f5240

The next three commands are just to verify that the symbols are loaded correctly:
----------------------------------------------------------------------------------------------------------------------
(gdb) info functions CoreHandleProtocol
All functions matching regular expression "CoreHandleProtocol":
File /.../edk2/MdeModulePkg/Core/Dxe/Hand/Handle.c:
EFI_STATUS CoreHandleProtocol(EFI_HANDLE, EFI_GUID *, void **);

(gdb) info address CoreHandleProtocol
Symbol "CoreHandleProtocol" is a function at address 0x7ea4aa9.

(gdb) info symbol 0x82F40A
_ModuleEntryPoint in section .text of /home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/PcdPeim.debug

(gdb) b CoreHandleProtocol
(gdb) b *0x82F40A
Breakpoint 2 at 0x82f40a: file /home/koenigr/Memtest/git/edk2/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.c, line 33.

(gdb) target remote localhost:1234
Remote debugging using localhost:1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x000000000000fff0 in ?? ()

(gdb) c
Qemu starts to continue....
The debugger should stop at a breakpoint, so that we could do source code level debug.

!!!BUT NOTHING HAPPENS.!!
OVMF.fd starts und runs until the Shell is loaded and is waiting for user input. BUT NO STOP at any breakpoint.

Do you have any suggestions what might be the reason why it does not work?

Thanks in advance,
Regina König

[-- Attachment #2: Type: text/html, Size: 9921 bytes --]

Re: [edk2-devel] Debugging Ovmf with GDB: No symbol is recognized

[Oliver Steffen]

Hi Regina,

I am not sure if I can help you with exactly the approach you are describing.
Are you aware of the efi_gdb.py script in BaseToosl/Scripts?
This can be used to debug OVMF with Qemu and gdb.

See these messages:
https://edk2.groups.io/g/devel/message/89621
https://edk2.groups.io/g/devel/message/77969

- Oliver

On Mon, May 23, 2022 at 3:03 AM koenig_regina via groups.io
<koenig_regina=arcor.de@groups.io> wrote:
>
> Hi, I am trying to debug OVMF as suggested in https://retrage.github.io/2019/12/05/debugging-ovmf-en.html.
> Almost every step seems to work fine.
>
> I built edk2 as follow:
> ------------------------------
> $ git clone git@github.com:tianocore/edk2.git\
> $ cd edk2$ git submodule update --init --recursive
> $ make -C BaseTools
> $ source ./edksetup.sh
> $ build -p OvmfPkg/OvmfPkgX64.dsc -b DEBUG -a X64 -t GCC5
>
>
> My Makefile looks like this:
> --------------------------------------
> #!/usr/bin/env make
>
> SHELL=/bin/bash
>
> LOG=debug.log
> OVMFBASE=edk2/Build/OvmfX64/DEBUG_GCC5/
> OVMFCODE=$(OVMFBASE)/FV/OVMF_CODE.fd
> OVMFVARS=$(OVMFBASE)/FV/OVMF_VARS.fd
> QEMU=qemu-system-x86_64
> QEMUFLAGS=-drive format=raw,file=fat:rw:image \
>           -drive if=pflash,format=raw,readonly,file=$(OVMFCODE) \
>           -drive if=pflash,format=raw,file=$(OVMFVARS) \
>           -debugcon file:$(LOG) -global isa-debugcon.iobase=0x402 \
>           -serial stdio \
>           -nographic \
>           -nodefaults
>
> run:
>     $(QEMU) $(QEMUFLAGS)
>
> debug:
>     $(QEMU) $(QEMUFLAGS) -s -S
>
> .PHONY: run debug
>
> As first step, I let it run to get a debug.log where all the loading addresses are stored:
> ---------------------------------------------------------------------------------------------------------------------
> $ make run
>
>
> Here an example of the information stored in debug.log:
> --------------------------------------------------------------------------------
> $ less debug.log
> ...
> The 0th FV start address is 0x0000082000
> ...
> Loading PEIM at 0x0000082BFC0
>     Entry Point = 0x0000082F40A PcdPeim.efi
> ...
>
>
> To extract the .text section from *.efi binaries, I need peinfo:
> -----------------------------------------------------------------------------------------
> $ git clone git@github.com:retrage/peinfo.git
> $ cd peinfo
> $ make
>
> I use peinfo in a bash script (gen_symbol_offset.sh) to get the symbol addresses:
> ................................................................................................
> #!/bin/bash
>
> LOG="debug.log"
> BUILD="edk2/Build/OvmfX64/DEBUG_GCC5/X64"
> PEINFO="peinfo/peinfo"
>
> cat ${LOG} | grep Loading | grep -i efi | while read LINE; do
>   BASE="`echo ${LINE} | cut -d " " -f4`"
>   NAME="`echo ${LINE} | cut -d " " -f6 | tr -d "[:cntrl:]"`"
>   ADDR="`${PEINFO} ${BUILD}/${NAME} \
>         | grep -A 5 text | grep VirtualAddress | cut -d " " -f2`"
>   TEXT="`python -c "print(hex(${BASE} + ${ADDR}))"`"
>   SYMS="`echo ${NAME} | sed -e "s/\.efi/\.debug/g"`"
>   echo "add-symbol-file ${BUILD}/${SYMS} ${TEXT}"
> done
>
> ...and create a script for gdb to add the symbol files:
> -----------------------------------------------------------------------------
> $ bash gen_symbol_offsets.sh > gdbscript
> $ cat gdb
> ...
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/PcdPeim.debug 0x82c380
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/ReportStatusCodeRouterPei.debug 0x831080
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/StatusCodeHandlerPei.debug 0x833100
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/PlatformPei.debug 0x835100
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/PeiCore.debug 0x7ee8240
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/DxeIpl.debug 0x7ee3240
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/S3Resume2Pei.debug 0x7edf240
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/CpuMpPei.debug 0x7ed6240
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/DxeCore.debug 0x7ea8240
> add-symbol-file edk2/Build/OvmfX64/DEBUG_GCC5/X64/DevicePathDxe.debug 0x7b8f240
> ...
>
> Second step is to run it again with -s -S flags, Qemu waits for connection
> ----------------------------------------------------------------
> $ make debug
>
>
> In a second Terminal I type:
> -------------------------------------------------
> $ gdb
> (gdb) source gdbscript
> ....
> add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/UsbBusDxe.debug" at
>         .text_addr = 0x6c85240
> add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/UsbKbDxe.debug" at
>         .text_addr = 0x6cb3240
> add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/UsbMassStorageDxe.debug" at
>         .text_addr = 0x6c6d240
> add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/QemuVideoDxe.debug" at
>         .text_addr = 0x6c66240
> add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/VirtioGpuDxe.debug" at
>         .text_addr = 0x6c60240
> add symbol table from file "/home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/Shell.debug" at
>         .text_addr = 0x64f5240
>
> The next three commands are just to verify that the symbols are loaded correctly:
> ----------------------------------------------------------------------------------------------------------------------
> (gdb) info functions CoreHandleProtocol
> All functions matching regular expression "CoreHandleProtocol":
> File /.../edk2/MdeModulePkg/Core/Dxe/Hand/Handle.c:
> EFI_STATUS CoreHandleProtocol(EFI_HANDLE, EFI_GUID *, void **);
>
> (gdb) info address CoreHandleProtocol
> Symbol "CoreHandleProtocol" is a function at address 0x7ea4aa9.
>
> (gdb) info symbol 0x82F40A
> _ModuleEntryPoint in section .text of /home/koenigr/Memtest/git/edk2/Build/OvmfX64/DEBUG_GCC5/X64/PcdPeim.debug
>
>
> (gdb) b CoreHandleProtocol
> (gdb) b *0x82F40A
> Breakpoint 2 at 0x82f40a: file /home/koenigr/Memtest/git/edk2/MdePkg/Library/PeimEntryPoint/PeimEntryPoint.c, line 33.
>
> (gdb) target remote localhost:1234
> Remote debugging using localhost:1234
> warning: No executable has been specified and target does not support
> determining executable automatically.  Try using the "file" command.
> 0x000000000000fff0 in ?? ()
>
> (gdb) c
> Qemu starts to continue....
> The debugger should stop at a breakpoint, so that we could do source code level debug.
>
> !!!BUT NOTHING HAPPENS.!!
> OVMF.fd starts und runs until the Shell is loaded and is waiting for user input. BUT NO STOP at any breakpoint.
>
> Do you have any suggestions what might be the reason why it does not work?
>
> Thanks in advance,
> Regina König
> 

Re: [edk2-devel] Debugging Ovmf with GDB: No symbol is recognized

[Moon Fault]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

*Dear Regina König,*

I came across your post, regarding the issue with debugging OVMF using GDB where the breakpoints weren't being hit despite loading the symbols correctly. I'm currently facing the exact same problem and was wondering if you were able to find a solution.

If you managed to resolve the issue, could you please share how you did it? It would be incredibly helpful for me as I'm stuck at the same point.

Thank you so much for your time and any guidance you can offer!

Best regards,

Mahsa


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120408): https://edk2.groups.io/g/devel/message/120408
Mute This Topic: https://groups.io/mt/91279461/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 1364 bytes --]

Re: [edk2-devel] Debugging Ovmf with GDB: No symbol is recognized

[Andrew Fish via groups.io]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

I contributed the efi_gdb.py scripts. The gdb scripts figure out the symbols that exist when you connect. They scripts can walk the current frame, or if you are in DXE they can usually figure out the table of all the symbols that got loaded up until this point. But that only represents what was loaded when you connect. It might be possible to connect prior to the driver/app being loaded so the symbols will not exist. 

I use lldb, not gdb, so I might be botching the gdb details but you can set a pending breakpoint waiting on symbols to get loaded but you still require some mechanism for symbols to load. In the emulator and the other EFI debugger symbols get loaded as modules get loaded. These scripts don’t do that, they just load symbols when you connect, or run the `efi symbols` command. They basically have some kind of stop hook on when a new module gets loaded and load the symbols then. Bad news this generic gdb/lldb scheme does not depend on that, good news is it makes it really easy to use the scheme with any gdb-remote (JTAG debugger, OVMF, hardware emulator, etc.) . 

Worst case you can add a  CpuDeadLoop(); [1] and then connect and load symbols and step over to debug. 

[1] https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/efi_gdb.py#L26

Thanks,

Andrew Fish

> On Aug 25, 2024, at 12:05 PM, Moon Fault <farahanimahsa99@gmail.com> wrote:
> 
> Dear Regina König,
> 
> I came across your post, regarding the issue with debugging OVMF using GDB where the breakpoints weren't being hit despite loading the symbols correctly. I'm currently facing the exact same problem and was wondering if you were able to find a solution.
> 
> If you managed to resolve the issue, could you please share how you did it? It would be incredibly helpful for me as I'm stuck at the same point.
> 
> Thank you so much for your time and any guidance you can offer!
> 
> Best regards,
> 
> Mahsa
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120409): https://edk2.groups.io/g/devel/message/120409
Mute This Topic: https://groups.io/mt/91279461/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 3344 bytes --]

Re: [edk2-devel] Debugging Ovmf with GDB: No symbol is recognized

[Moon Fault]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

Dear Andrew,

Thank you for your detailed explanation regarding the behavior of symbol loading in GDB when debugging OVMF.

I just want to make sure I’ve understood your points correctly:

* 

*Symbol Loading Timing:* The issue I’m facing might occur because I’m connecting to GDB before all the necessary drivers or applications have been loaded. As a result, the symbols for these modules aren’t available at the time of connection, leading to breakpoints not being hit.

* 

*Pending Breakpoints:* You mentioned that it’s possible to set pending breakpoints in GDB, which will activate once the relevant symbols are loaded. However, this still requires some mechanism to ensure that the symbols are eventually loaded as the modules initialize.

* 

*Using CpuDeadLoop():* If I insert a CpuDeadLoop(); after the modules are loaded, I can connect GDB, ensure the symbols are loaded, and then step over the loop to continue debugging from that point.

Could you confirm if I’ve captured this correctly? Also, is using CpuDeadLoop(); the best approach to guarantee that all symbols are loaded before continuing the debugging process?

Thank you again for your insights!

Best regards,
Mahsa


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120412): https://edk2.groups.io/g/devel/message/120412
Mute This Topic: https://groups.io/mt/91279461/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 2198 bytes --]

Re: [edk2-devel] Debugging Ovmf with GDB: No symbol is recognized

[Andrew Fish via groups.io]

[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]



> On Aug 27, 2024, at 1:32 AM, Moon Fault <farahanimahsa99@gmail.com> wrote:
> 
> Dear Andrew,
> 
> Thank you for your detailed explanation regarding the behavior of symbol loading in GDB when debugging OVMF.
> 
> I just want to make sure I’ve understood your points correctly:
> 
> Symbol Loading Timing: The issue I’m facing might occur because I’m connecting to GDB before all the necessary drivers or applications have been loaded. As a result, the symbols for these modules aren’t available at the time of connection, leading to breakpoints not being hit.
> 
> Pending Breakpoints: You mentioned that it’s possible to set pending breakpoints in GDB, which will activate once the relevant symbols are loaded. However, this still requires some mechanism to ensure that the symbols are eventually loaded as the modules initialize.
> 
> Using CpuDeadLoop(): If I insert a CpuDeadLoop(); after the modules are loaded, I can connect GDB, ensure the symbols are loaded, and then step over the loop to continue debugging from that point.
> 
> Could you confirm if I’ve captured this correctly? Also, is using CpuDeadLoop(); the best approach to guarantee that all symbols are loaded before continuing the debugging process?
> 
Masha,

Obviously I’m guessing a little bit about your specific case but you did a good job summarizing my points. In general during a UEFI boot the DXE Core will “dispatch” drivers in an order based on when they are needed. These drivers are loaded and relocated into malloc’ed memory, so until they are loaded you can’t really load symbols for them. 

If you get to the UEFI Shell things are generally loaded so you can also just try trigging things from there, but obviously you need to attach 1st. 

Thanks,

Andrew Fish
> Thank you again for your insights!
> 
> Best regards,
> Mahsa
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120416): https://edk2.groups.io/g/devel/message/120416
Mute This Topic: https://groups.io/mt/91279461/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 3309 bytes --]