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.

_._,_._,_