Re: [edk2] [RFC 0/1] Stack trace support in X64 exception handling

2017-11-14 Thread Paulo Alcantara 
gged in 
MSR_SANDY_BRIDGE_LASTBRANCH_n_FROM_IP and 
MSR_SANDY_BRIDGE_LASTBRANCH_n_TO_IP, and the current depth is tracked 
in MSR_LASTBRANCH_TOS.  This works quite well.  Gen10 (Sky Lake) 
processors support 32 LASTBRANCH_n MSR pairs, which is sufficient in 
almost all cases.


Different processor generations have different branch recording 
capabilities, and different numbers of LASTBRANCH_n MSRs; see Intel's 
manuals for details.


Thanks,
Brian



Thanks!

Jeff

*发件人: *Paulo Alcantara <mailto:pca...@zytor.com>
*发送时间: *2017年11月14日21:23
*收件人: *edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> 
<mailto:edk2-devel@lists.01.org>
*抄送: *Rick Bramley <mailto:richard.bram...@hp.com>; Laszlo Ersek 
<mailto:ler...@redhat.com>; Andrew Fish <mailto:af...@apple.com>; 
Eric Dong <mailto:eric.d...@intel.com>
*主题: *Re: [edk2] [RFC 0/1] Stack trace support in X64 exception 
handling


Hi,

On 14/11/2017 10:47, 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.


I've attached a file to show you how the trace would look like.

Thanks!
Paulo



Thanks!
Paulo

Repo: https://github.com/pcacjr/edk2.git
Branch: stacktrace_x64

Cc: Rick Bramley <richard.bram...@hp.com 
<mailto:richard.bram...@hp.com>>

Cc: Andrew Fish <af...@apple.com <mailto:af...@apple.com>>
Cc: Eric Dong <eric.d...@intel.com <mailto:eric.d...@intel.com>>
Cc: Laszlo Ersek <ler...@redhat.com <mailto:ler...@redhat.com>>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pca...@zytor.com 
<mailto:pca...@zytor.com>>

---

Paulo Alcantara (1):
UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
| 344 +++-

1 file changed, 342 insertions(+), 2 deletions(-)




___
edk2-devel mailing list
edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel



--

   Brian



  "Most people would like to be delivered from temptation but would
   like it to keep in touch."
  -- Robert Orben
___
edk2-devel mailing list
edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel






___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC 0/1] Stack trace support in X64 exception handling

2017-11-14 Thread Brian J. Johnson 
.bram...@hp.com>; Laszlo Ersek 
<mailto:ler...@redhat.com>; Andrew Fish <mailto:af...@apple.com>; 
Eric Dong <mailto:eric.d...@intel.com>
*主题: *Re: [edk2] [RFC 0/1] Stack trace support in X64 exception 
handling


Hi,

On 14/11/2017 10:47, 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.


I've attached a file to show you how the trace would look like.

Thanks!
Paulo



Thanks!
Paulo

Repo: https://github.com/pcacjr/edk2.git
Branch: stacktrace_x64

Cc: Rick Bramley <richard.bram...@hp.com 
<mailto:richard.bram...@hp.com>>

Cc: Andrew Fish <af...@apple.com <mailto:af...@apple.com>>
Cc: Eric Dong <eric.d...@intel.com <mailto:eric.d...@intel.com>>
Cc: Laszlo Ersek <ler...@redhat.com <mailto:ler...@redhat.com>>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pca...@zytor.com 
<mailto:pca...@zytor.com>>

---

Paulo Alcantara (1):
UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
| 344 +++-

1 file changed, 342 insertions(+), 2 deletions(-)




___
edk2-devel mailing list
edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel



--

   Brian



  "Most people would like to be delivered from temptation but would
   like it to keep in touch."
  -- Robert Orben
___
edk2-devel mailing list
edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel





--
Brian J. Johnson
Enterprise X86 Lab

Hewlett Packard Enterprise
brian.john...@hpe.com

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC 0/1] Stack trace support in X64 exception handling

2017-11-14 Thread Andrew Fish 

> On Nov 14, 2017, at 8:33 AM, Brian J. Johnson <brian.john...@hpe.com> wrote:
> 
> On 11/14/2017 09:37 AM, Paulo Alcantara wrote:
>> Hi Fan,
>> On 14/11/2017 12:03, Fan Jeff wrote:
>>> Paul,
>>> 
>>> I like this feature very much. Actually, I did some POC one year ago but I 
>>> did finalize it.
>>> 
>>> In my POC, I could use EBP to tack the stack frame on IAS32 arch.
>>> 
>>> But for x64, I tried to use –keepexceptiontable flag to explain stack frame 
>>> from the debug section of image.
>>> 
>>> I may workson MSFT toolchain, but it did now work well for GCC toolchain.
>>> 
>>> I think Eric could help to verify MSFT for your patch. If it works well, 
>>> that’s will be great!
>>> 
>>> Say again, I like this feature!!!:-)
>> Cool! Your help would be really appreciable! If we get this working for X64 
>> in both toolchains, that should be easy to port it to IA-32 as well.
>> Thank you very much for willing to help on that.
>> Paulo
> 
> Great feature!  You do need some sort of sanity check on the RIP and RBP 
> values, though, so if the stack gets corrupted or the RIP is nonsense from 
> following a bad pointer, you don't start dereferencing garbage addresses and 
> trigger an exception loop.
> 

Brian,

This was a long time ago and my memory might be fuzzy I think we talked to 
some debugger folks about unwinding the stack and they mentioned it was common 
for the C runtime to have a return address or frame pointer have a zero value 
so the unwind logic knows when to stop. This is in addition to generic sanity 
checking. 

We got an extra push $0 added to the stack switch to help with stack unwind. 
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/SwitchStack.S
 
<https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/SwitchStack.S>

If might be a good idea to have a PCD for the max number of stack frames to 
display as a fallback for the error check. For X64 you may also have to add a 
check for a non-cononical address as that will GP fault. 

Thanks,

Andrew Fish


> For at least some versions of Microsoft's IA32 compiler, it's possible to 
> compile using EBP as a stack frame base pointer (like gcc) by using the 
> "/Oy-" switch.  The proposed unwind code should work in that case. The X64 
> compiler doesn't support this switch, though.
> 
> AFAIK the only way to unwind the stack with Microsoft's X64 compilers is to 
> parse the unwind info in the .pdata and .xdata sections.  Genfw.exe usually 
> strips those sections, but the "--keepexceptiontable" flag will preserve 
> them, as Jeff pointed out.  I've looked hard for open source code to decode 
> them, but haven't found any, even though the format is well documented.  And 
> I haven't gotten around to writing it myself.  I'd love it if someone could 
> contribute the code!
> 
> Another possibility is to use the branch history MSRs available on some 
> x86-family processors.  Recent Intel processors can use them as a stack, as 
> opposed to a circular list, so they can record a backtrace directly. (I'm not 
> familiar with AMD processors' capabilities.)  You can enable call stack 
> recording like this:
> 
>  #define LBR_ON_FLAG   0x0001
>  #define IA32_DEBUGCTL 0x1D9
>  #define CALL_STACK_SET_FLAG 0x3C4
>  #define CALL_STACK_CLR_FLAG 0xFC7
>  #define MSR_LBR_SELECT 0x1C8
> 
>  //
>  // Enable branch recording
>  //
>  LbControl = AsmReadMsr64 ((UINT32)IA32_DEBUGCTL);
>  LbControl |= LBR_ON_FLAG;
>  AsmWriteMsr64 ((UINT32)IA32_DEBUGCTL, LbControl);
> 
>  //
>  // Configure for call stack
>  //
>  LbSelect = AsmReadMsr64 ((UINT32)MSR_LBR_SELECT);
>  LbSelect &= CALL_STACK_CLR_FLAG;
>  LbSelect |= CALL_STACK_SET_FLAG;
>  AsmWriteMsr64((UINT32)MSR_LBR_SELECT, LbSelect);
> 
> The EIP/RIP values are logged in MSR_SANDY_BRIDGE_LASTBRANCH_n_FROM_IP and 
> MSR_SANDY_BRIDGE_LASTBRANCH_n_TO_IP, and the current depth is tracked in 
> MSR_LASTBRANCH_TOS.  This works quite well.  Gen10 (Sky Lake) processors 
> support 32 LASTBRANCH_n MSR pairs, which is sufficient in almost all cases.
> 
> Different processor generations have different branch recording capabilities, 
> and different numbers of LASTBRANCH_n MSRs; see Intel's manuals for details.
> 
> Thanks,
> Brian
> 
>>> 
>>> Thanks!
>>> 
>>> Jeff
>>> 
>>> *发件人: *Paulo Alcantara <mailto:pca...@zytor.com>
>>> *发送时间: *2017年11月14日21:23
>>> *收件人: *edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
>>> *抄送: *Rick Bramley <mailto:richard.bram...@hp.com>; Laszlo Ersek

Re: [edk2] [RFC 0/1] Stack trace support in X64 exception handling

2017-11-14 Thread Paulo Alcantara 

Hi,

On 14/11/2017 10:47, 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.


I've attached a file to show you how the trace would look like.

Thanks!
Paulo



Thanks!
Paulo

Repo:   https://github.com/pcacjr/edk2.git
Branch: stacktrace_x64

Cc: Rick Bramley 
Cc: Andrew Fish 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---

Paulo Alcantara (1):
   UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

  UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 344 
+++-
  1 file changed, 342 insertions(+), 2 deletions(-)



 X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID -  
ExceptionData - 0002  I:0 R:0 U:0 W:1 P:0 PK:0 S:0
RIP  - 7E510F7F, CS  - 0038, RFLAGS - 00010202
RAX  - , RCX - 7EA01318, RDX - 7F6EE018
RBX  - 00810248, RSP - 7F762C70, RBP - 7F762CB0
RSI  - 0007, RDI - 7EA01418
R8   - 7E513A88, R9  - 7EA01798, R10 - 0036
R11  - 00D7, R12 - , R13 - 
R14  - , R15 - 
DS   - 0030, ES  - 0030, FS  - 0030
GS   - 0030, SS  - 0030
CR0  - 80010033, CR2 - , CR3 - 7F701000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - 0FF0, DR7 - 0400
GDTR - 7F6EEA98 0047, LDTR - 
IDTR - 7EEF2018 0FFF,   TR - 
FXSAVE_STATE - 7F7628D0

Back trace:
0 0x7E510F7F @ 0x7E509000+0x7F7E (0x7F762CB0) in 
PartitionDxe.dll
1 0x7E51135D @ 0x7E509000+0x835C (0x7F762CE0) in 
PartitionDxe.dll
2 0x7E50C116 @ 0x7E509000+0x3115 (0x7F762D20) in 
PartitionDxe.dll
3 0x7F776972 @ 0x7E509000+0x126D971 (0x7F762DB0) in 
PartitionDxe.dll
4 0x7F78EE08 @ 0x7E509000+0x1285E07 (0x7F762E30) in 
PartitionDxe.dll
5 0x7F791343 @ 0x7E509000+0x1288342 (0x7F762F60) in 
PartitionDxe.dll
6 0x7F791AC7 @ 0x7E509000+0x1288AC6 (0x7F762F90) in 
PartitionDxe.dll
7 0x7F767DDB @ 0x7E509000+0x125EDDA (0x7F762FC0) in 
PartitionDxe.dll
8 0x7F7DF75F @ 0x7E509000+0x12D675E (0x7B7DC840) in 
PartitionDxe.dll
9 0x7F7E5546 @ 0x7E509000+0x12DC545 (0x7B7DC8C0) in 
PartitionDxe.dll
10 0x7F7E4312 @ 0x7E509000+0x12DB311 (0x7B7DCA30) in 
PartitionDxe.dll
11 0x7F7F0DB9 @ 0x7E509000+0x12E7DB8 (0x7B7DCF80) in 
PartitionDxe.dll
12 0x008286E9 @ 0x00820140+0x85A8 (0x7B7DD4D0) in 
PeiCore.dll
13 0x0083092F @ 0x00820140+0x107EE (0x00817600) in 
PeiCore.dll
14 0x00831574 @ 0x00820140+0x11433 (0x008176D0) in 
PeiCore.dll
15 0x00828D9B @ 0x00820140+0x8C5A (0x00817C20) in 
PeiCore.dll
16 0x0083238A @ 0x00820140+0x12249 (0x00817C50) in 
PeiCore.dll
17 0x00824312 @ 0x00820140+0x41D1 (0x00817C80) in 
PeiCore.dll
18 0xFFFD4291 @ 0x00820140+0xFF7B4150 (0x00817CE0) in 
PeiCore.dll
19 0xFFFCF578 @ 0x00820140+0xFF7AF437 (0x00817D10) in 
PeiCore.dll
20 0xFFFD422C @ 0x00820140+0xFF7B40EB (0x00817FD0) in 
PeiCore.dll
21 0xFFFD4489 @ 0x00820140+0xFF7B4348 (0xFFFCC000) in 
PeiCore.dll

PartitionDxe.dll (ImageBase=0x7E509000, EntryPoint=0x7E50C01F):
/home/pcacjr/src/edk2.git/Build/OvmfX64/NOOPT_GCC5/X64/MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe/DEBUG/PartitionDxe.dll
PeiCore.dll (ImageBase=0x00820140, EntryPoint=0x008242EC):
/home/pcacjr/src/edk2.git/Build/OvmfX64/NOOPT_GCC5/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll

Stack dump:
0x7F762C70: 7E5137E0 
0x7F762C80: 7E513A88 0100
0x7F762C90: 7F762CB0 
0x7F762CA0: 7F762CE0

[edk2] [RFC 0/1] Stack trace support in X64 exception handling

2017-11-14 Thread Paulo Alcantara 
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_x64

Cc: Rick Bramley 
Cc: Andrew Fish 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara 
---

Paulo Alcantara (1):
  UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support

 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 344 
+++-
 1 file changed, 342 insertions(+), 2 deletions(-)

-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel