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