Hi Andrew, On Thu, November 16, 2017 3:01 am, Andrew Fish wrote: > Paulo, > > Those attached stack traces don't look right. What about the new ones? Thanks! Paulo > > Thanks, > > Andrew Fish > >> On Nov 15, 2017, at 5:46 PM, Paulo Alcantara wrote: >> >> 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 >>> Cc: Andrew Fish >>> Cc: Eric Dong >>> Cc: Laszlo Ersek >>> Cc: "Brian J. Johnson" >>> Cc: Jeff Fan >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Paulo Alcantara >>> --- >>> 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 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> > -- Paulo Alcantara, HP Inc. Speaking for myself only.