Unable to do source level debug for EDK2 OVMF using qemu (Bugzilla Bug 3194)

[tianocore-issues]

This issue was created automatically with bugzilla2github

Bugzilla Bug 3194

Date: 2021-01-31T10:34:13+00:00
From: Ying Fang <>
To: @Laurie0131
CC: @ajfish, @lgao4

Last updated: 2021-07-27T05:05:30+00:00

[tianocore-issues]

Comment 14936

Date: 2021-01-31 10:34:13 +0000
From: Ying Fang <>

• Industry Specification: ---
• Release Observed: edk2-stable202008
• Releases to Fix: edk2-stable202008
• Target OS: ---
• Bugzilla Assignee(s): @Laurie0131

Hi,
I am doing source level debug for EDK2 OVMF using QEMU following the guide posted
at: https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB

I can get the debug.log with the 'Loading' information and I set a breakpoint at
UefiMain. However when qemu is lauchned and remote gdb is attached, I cannot
hit the breakpoint at UefiMain.

I tried qemu form 4.1.0 to 5.2 version and edk2-stable202008. I can do all
procedure described at the wiki page, but I cannot break the UefiMain, the
uefi goes down to UiApp directly without stopped at UefiMain.

I had tried it for about one week, still cannot figure it out.
So I am not sure whether the wiki page is right with the latest EDK2 release and Qemu. Maybe the content is outdated or somthing is wrong.

add symbol table from file "Build/OvmfX64/DEBUG_GCC5/X64/VirtioGpuDxe.debug" at
.text_addr = 0x7ec86240
.data_addr = 0x7ec8b4c0
add symbol table from file "Build/OvmfX64/DEBUG_GCC5/X64/Shell.debug" at
.text_addr = 0x7e95b240
.data_addr = 0x7e9d46c0
add symbol table from file "Build/OvmfX64/DEBUG_GCC5/X64/UiApp.debug" at
.text_addr = 0x7ead3240
.data_addr = 0x7eaef9c0

(gdb) b UefiMain
Breakpoint 1 at 0x7e961b5f: file /home/fang/code/opensrc/edk2/ShellPkg/Application/Shell/Shell.c, line 345.
(gdb)

(gdb) target remote :1234
(gdb) c
Continuing.

The UefiMain breakpoint was never triggered.

[tianocore-issues]

Comment 14956

Date: 2021-02-02 07:30:03 +0000
From: @lersek

Assigning to Laurie for triage / analysis -- I've never used the method described in the Wiki article. Currently the Wiki article has 4 commits, all from Laurie. Thanks!

[tianocore-issues]

Comment 14967

Date: 2021-02-02 21:49:53 +0000
From: @lgao4

Laurie: can you check it?

[tianocore-issues]

Comment 14986

Date: 2021-02-03 00:23:19 +0000
From: @ajfish

Stupid question as I'm mostly an lldb user...

But you are getting an implied target from the add-symbol-file command and you set the breakpoint. After all this you tell gdb to create a new target via the target remote command. I know from lldb that QEMU responds back with an XML target description so to me it seems like the target could get redefined and thus the previous break point could get lost?

So maybe doing the target remote localhost:1234 1st and the add-symbol-file and break point setting later would fix this issue?

[tianocore-issues]

Comment 14988

Date: 2021-02-03 00:40:43 +0000
From: @ajfish

Also I notice the instructions make the assumption that if you load an UEFI Shell application over and over it will load to the same address. I'm not sure how reliable that is especially if you over flow the firmwares original memory layout buckets.

[tianocore-issues]

Comment 15002

Date: 2021-02-03 11:47:04 +0000
From: @Laurie0131

The example from the wiki page is using Ubuntu 16.04. and on EDK II from 2018. I have not tried this example on a later Ubuntu with a later edk2.

The Wiki example is using an Application loaded from the UEFI Shell not loading the shell again. So the breakpoint of UefiMain from the UEFI Shell application would not be executed again since the UEFI Shell is already loaded.

Another example at this link: http://eszkadev.blogspot.com/2016/02/edkii-and-qemu-remote-debugging-with-gdb.html

[tianocore-issues]

Comment 15027

Date: 2021-02-05 23:37:28 +0000
From: Ying Fang <>

(In reply to Andrew Fish from comment #3)
> Stupid question as I'm mostly an lldb user...
>
> But you are getting an implied target from the add-symbol-file command and
> you set the breakpoint. After all this you tell gdb to create a new target
> via the target remote command. I know from lldb that QEMU responds back
> with an XML target description so to me it seems like the target could get
> redefined and thus the previous break point could get lost?
>
> So maybe doing the target remote localhost:1234 1st and the
> add-symbol-file and break point setting later would fix this issue?

I have also tried to do target remote :1234 and then load the symbol file.
But it stil hit the breakpoint given.

[tianocore-issues]

Comment 15028

Date: 2021-02-05 23:39:03 +0000
From: Ying Fang <>

(In reply to Andrew Fish from comment #3)
> Stupid question as I'm mostly an lldb user...
>
> But you are getting an implied target from the add-symbol-file command and
> you set the breakpoint. After all this you tell gdb to create a new target
> via the target remote command. I know from lldb that QEMU responds back
> with an XML target description so to me it seems like the target could get
> redefined and thus the previous break point could get lost?
>
> So maybe doing the target remote localhost:1234 1st and the
> add-symbol-file and break point setting later would fix this issue?

I have also tried to do target remote :1234 and then load the symbol file.
But it stil hit the breakpoint given.

[tianocore-issues]

Comment 15029

Date: 2021-02-05 23:48:04 +0000
From: Ying Fang <>

(In reply to Laurie Jarlstrom from comment #5)
> The example from the wiki page is using Ubuntu 16.04. and on EDK II from
> 2018. I have not tried this example on a later Ubuntu with a later edk2.
>
> The Wiki example is using an Application loaded from the UEFI Shell not
> loading the shell again. So the breakpoint of UefiMain from the UEFI Shell
> application would not be executed again since the UEFI Shell is already
> loaded.
>
> Another example at this link:
> http://eszkadev.blogspot.com/2016/02/edkii-and-qemu-remote-debugging-with-
> gdb.html

Yes you are right。
As far as i am concerned, if EKD2 has support for source level debug
we can do source level debug for both UefiApp or edk2 at DXE/BDS stage.
But however I cannot reproduce it.

I have tried from qemu-4.1.0 to qemu-5.2.0 and edk2-stable202008.
Both OVMF and ArmVirt platform are tried and the result is the same.
Thus edk2 just goes throught the breakpoint at DxeMain and UefiMain are never tirggered.

[tianocore-issues]

Comment 15031

Date: 2021-02-06 20:10:18 +0000
From: Ying Fang <>

(In reply to Ying Fang from comment #7)
> (In reply to Andrew Fish from comment #3)
> > Stupid question as I'm mostly an lldb user...
> >
> > But you are getting an implied target from the add-symbol-file command and
> > you set the breakpoint. After all this you tell gdb to create a new target
> > via the target remote command. I know from lldb that QEMU responds back
> > with an XML target description so to me it seems like the target could get
> > redefined and thus the previous break point could get lost?
> >
> > So maybe doing the target remote localhost:1234 1st and the
> > add-symbol-file and break point setting later would fix this issue?
>
> I have also tried to do target remote :1234 and then load the symbol file.
> But it stil hit the breakpoint given.

Sorry I mean, it still can not hit the breakpoint given.

[tianocore-issues]

Comment 15086

Date: 2021-02-21 20:59:52 +0000
From: Ying Fang <>

Any further progress about source level debug for EDK2 here ?

[r1chard-lyu]

Is there any update on this?