Re: [edk2] Issue of step by step debugging of OVMF SEC code in QEMU

It is generally hard to debug across x86 processor mode transitions, and to debug 16-bit real mode code with modern tools. There are a few places in the x86 that still require 16-bit real mode for handoffs (like the reset vector) so you tend to hit this issue more in debugging firmware. Thanks,

Re: [edk2] Issue of step by step debugging of OVMF SEC code in QEMU

Hi Andrew, THe problem is solved, after the SEC code switch to protected mode, gdb can work well now At 2017-08-04 11:26:16, "wang xiaofeng" wrote: HI Andrew, How can I adjust the debugger to correct mode? Or I have to enable the debug after swtich to protected mode? A

Re: [edk2] Issue of step by step debugging of OVMF SEC code in QEMU

HI Andrew, How can I adjust the debugger to correct mode? Or I have to enable the debug after swtich to protected mode? At 2017-08-04 10:57:16, "Andrew Fish" wrote: >The reset vector is 16-bit real mode, so you have the debugger in the wrong >mode. The code should transition to 32 b

Re: [edk2] Issue of step by step debugging of OVMF SEC code in QEMU

The reset vector is 16-bit real mode, so you have the debugger in the wrong mode. The code should transition to 32 bit protected early in the flow. Sent from my iPhone > On Aug 3, 2017, at 7:47 PM, wang xiaofeng wrote: > > Hello, > I am tring to add my own SEC code base on OVMF and run o

[edk2] Issue of step by step debugging of OVMF SEC code in QEMU

Hello, I am tring to add my own SEC code base on OVMF and run on QEMU. Since the code cannot run I need to step to step trace the assembly code . The hang point is very early before I can use either UDK or debug serial output. I tried to use gdb to connect to QEMU.I start gdb in anot