Hi,

On 11/15/2017 11:18 PM, Paulo Alcantara wrote:
> Hi,
> 
> This series adds stack trace support during a X64 CPU exception.
> 
> Informations like back trace, stack contents and image module names
> (that were part of the call stack) will be dumped out.
> 
> We already have such support in ARM/AArch64 (IIRC) exception handling
> (thanks to Ard), and then I thought we'd also deserve it in X64 and
> IA-32 platforms.
> 
> What do you think guys?
> 
> BTW, I've tested this only with OVMF (X64 only), using:
>    - gcc-6.3.0, GCC5, NOOPT
> 
> Any other tests  would be really appreciable.
> 
> Thanks!
> Paulo
> 
> Repo:   https://github.com/pcacjr/edk2.git
> Branch: stacktrace_v2
> 
> Cc: Rick Bramley <richard.bramley@hp.com>
> Cc: Andrew Fish <afish@apple.com>
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: "Brian J. Johnson" <brian.johnson@hpe.com>
> Cc: Jeff Fan <jeff.fan@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
> ---
> 
> v1 -> v2:
>    * Add IA32 arch support (GCC toolchain only)
>    * Replace hard-coded stack alignment value (16) with
>      CPU_STACK_ALIGNMENT.
>    * Check for proper stack and frame pointer alignments.
>    * Fix initialization of UnwoundStacksCount to 1.
>    * Move GetPdbFileName() to common code since it will be used by both
>      IA32 and X64 implementations.

Sorry for the delay in sending v2. It's holiday here :-)

FWIW, I've attached two files which contain stack trace dumps of IA32 
and X64 exceptions.

The new IA32 arch support is still limited to GCC only (that is, relying 
on frame pointers), but I'll start investing in a new solution that 
would work on both MSVC and GCC toolchains -- probably this weekend. If 
I come up with something, I'll let you know.

On IA32, I performed the same test as in X64 to trigger an NMI interrupt 
manually with: asm ("int $0x2") in PartitionDxe driver and watched out 
the call stack. The difference between the two dumps, regardless the CPU 
context, etc. is that we don't see the calls from PeiCore.dll. Then I 
figured out that the EIP gets a value of 0 before jumping to 
PartitionDxe's entry point.

I guess that's related to the "push $0" that Andrew mentioned earlier so 
the debugger knows when to stop unwinding. Although I can't see a "push 
0" equivalent neither in SwitchStack.nasm nor in SwitchStack.asm for X64
-- so we're able to see the calls within PeiCore.dll.

Thanks!
Paulo