From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.33; helo=mail-in23.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9A98920349D9B for ; Tue, 14 Nov 2017 09:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510680193; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WAv0JnJg3CkmfzPmWrTN2m+bQqZsfrRCdnEmqASswLc=; b=G8hYuppYeGkwht55X+aC+obmcAVD0wxqEKJi3032z6GICK6bbTCbFOHTbROGYm2e K6zY2CM+Glq3HJUMLukrMPZO0SqZuFGsOUUijnI4fi9NptxcHSx4U0T99AoPJ0NQ K7q1o4IgRlKrWSkIZzprEMTGoLI9reTAYsLXP/fuisN+NMW6ZhDwwU1/wTpXaLYi zKrhh1+UdEE5XtvqgXLEaAEmyUOrhwuzH2ER17ebNBQWTeYqkeemfLYI8Xt80Qc5 RVzzfFZGNWyZKOOMXtdw1afBniI/XUMB20MUsY9lRCkzNehfRg+JZSgNB2KKW14W 9Crf8X0iziPep1lIueye4Q==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id F6.EA.29340.0862B0A5; Tue, 14 Nov 2017 09:23:13 -0800 (PST) X-AuditID: 11ab0217-df6059c00000729c-ab-5a0b268066ab Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay8.apple.com (Apple SCV relay) with SMTP id BA.3D.22651.0862B0A5; Tue, 14 Nov 2017 09:23:12 -0800 (PST) MIME-version: 1.0 Received: from [17.114.153.77] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZF0096F4AN8PA0@nwk-mmpp-sz13.apple.com>; Tue, 14 Nov 2017 09:23:12 -0800 (PST) Sender: afish@apple.com From: Andrew Fish Message-id: <1038F835-BDA5-4BAD-8032-25C12E2C1BF7@apple.com> Date: Tue, 14 Nov 2017 09:23:11 -0800 In-reply-to: <5aad56cd-ae69-59d3-1598-453a94926802@hpe.com> Cc: Paulo Alcantara , Fan Jeff , "edk2-devel@lists.01.org" , Rick Bramley , Laszlo Ersek , Eric Dong To: "Brian J. Johnson" References: <8de9df9f-0386-8250-7c80-9a3cff65841e@zytor.com> <5aad56cd-ae69-59d3-1598-453a94926802@hpe.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRbChM021U444yWDSZz2JS3xY2iz2HjjJb bH4RbLHs2A4Wi32vPzJaXF57nt3ixOd5bA7sHo97zrB57Nq2k8lj165Gdo/Fe14yeXTP/sfi 8X7fVTaPEy1fWAPYo7hsUlJzMstSi/TtErgyXs/sZSpY9p2p4uj/G2wNjE9OMHUxcnJICJhI nLu2kaWLkYtDSGAtk8S9N/vYYBIti44zQyQOMUp83ryRFSTBKyAo8WPyPRYQm1kgTGLx3+WM EEVfGSVO3+piBEkIC4hLvDuziRnEZhNQllgx/wM7RLONxPebU1ggarwlXh96BmRzcLAIqEpc XpUNEuYUsJaY8KWTCWQms8B7RonH2yaCLRYR0JOYc/YFK8SyuUwSC7dOgTpVVuLW7Etgp0oI PGeTOHtpOvsERqFZSK6dheTaWUALmQXUJaZMyYUIa0s8eXeBFcJWk1j4exETsvgCRrZVjMK5 iZk5upl5RsZ6iQUFOal6yfm5mxhBcbeaSXwH4+fXhocYBTgYlXh4M5S5o4RYE8uKK3MPMUpz sCiJ897Z+jtSSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6ND0ZEdTTaSdbxZJftttM68UD55 0e/Gh5IVHyY8630dq64RVjxxbsaJQxP7fR2EU1YsfBlxZlvdrIySPPmrUeue73mpr7GisEtX 0HBf2689ws+KnFfzC938V2H50mpy5dcXDK6JgQLHw3IEp8bXvDFeXaya0vn/6PfYJ3Jzm7Ka 9oRnqXjOslBiKc5INNRiLipOBADz4kNJnAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUi2FB8Q7dBjTvK4Oh0UYtJfVvYLPYcOsps sflFsMWyYztYLPa9/shocXnteXaLE5/nsTmwezzuOcPmsWvbTiaPXbsa2T0W73nJ5NE9+x+L x/t9V9k8TrR8YQ1gj+KySUnNySxLLdK3S+DKeD2zl6lg2XemiqP/b7A1MD45wdTFyMkhIWAi 0bLoOHMXIxeHkMAhRonPmzeygiR4BQQlfky+xwJiMwuESSz+u5wRougro8TpW12MIAlhAXGJ d2c2MYPYbALKEivmf2CHaLaR+H5zCgtEjbfE60PPgGwODhYBVYnLq7JBwpwC1hITvnQygcxk FnjPKPF420SwxSICehJzzr5ghVg2l0li4dYpbBCnykrcmn2JeQIj/ywkB85CcuAsoB3MAuoS U6bkQoS1JZ68u8AKYatJLPy9iAlZfAEj2ypGgaLUnMRKC73EgoKcVL3k/NxNjOAoKUzbwdi0 3OoQowAHoxIPb4Yyd5QQa2JZcWUuMJQ4mJVEeHfO4ooS4k1JrKxKLcqPLyrNSS0+xCjNwaIk zqsvApQSSE8sSc1OTS1ILYLJMnFwSjUwMqs3qsprF/CbC566yHRl76NtQnHvNU43N/8Ncg8Q 3LTra/zuKw//LQ5UDVA8r/JeXv6/WHRcgIVK4ymDk5d68n5Nk598/EyF8kffh9PuWXY4Ku7h kLdb2zLRaNK2hUVRH2ZZ7mdiq391snHzulzuMyeMrGyKFx/82l/R05snI1fP+vGI5fO7SizF GYmGWsxFxYkAnRvUZ44CAAA= X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [RFC 0/1] Stack trace support in X64 exception handling X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 17:19:07 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Nov 14, 2017, at 8:33 AM, Brian J. Johnson = wrote: >=20 > On 11/14/2017 09:37 AM, Paulo Alcantara wrote: >> Hi Fan, >> On 14/11/2017 12:03, Fan Jeff wrote: >>> Paul, >>>=20 >>> I like this feature very much. Actually, I did some POC one year ago = but I did finalize it. >>>=20 >>> In my POC, I could use EBP to tack the stack frame on IAS32 arch. >>>=20 >>> But for x64, I tried to use =E2=80=93keepexceptiontable flag to = explain stack frame from the debug section of image. >>>=20 >>> I may workson MSFT toolchain, but it did now work well for GCC = toolchain. >>>=20 >>> I think Eric could help to verify MSFT for your patch. If it works = well, that=E2=80=99s will be great! >>>=20 >>> 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 >=20 > 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. >=20 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.=20 We got an extra push $0 added to the stack switch to help with stack = unwind.=20 = https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/S= witchStack.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.=20 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. >=20 > 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! >=20 > 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: >=20 > #define LBR_ON_FLAG 0x0000000000000001 > #define IA32_DEBUGCTL 0x1D9 > #define CALL_STACK_SET_FLAG 0x3C4 > #define CALL_STACK_CLR_FLAG 0xFC7 > #define MSR_LBR_SELECT 0x1C8 >=20 > // > // Enable branch recording > // > LbControl =3D AsmReadMsr64 ((UINT32)IA32_DEBUGCTL); > LbControl |=3D LBR_ON_FLAG; > AsmWriteMsr64 ((UINT32)IA32_DEBUGCTL, LbControl); >=20 > // > // Configure for call stack > // > LbSelect =3D AsmReadMsr64 ((UINT32)MSR_LBR_SELECT); > LbSelect &=3D CALL_STACK_CLR_FLAG; > LbSelect |=3D CALL_STACK_SET_FLAG; > AsmWriteMsr64((UINT32)MSR_LBR_SELECT, LbSelect); >=20 > 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. >=20 > Different processor generations have different branch recording = capabilities, and different numbers of LASTBRANCH_n MSRs; see Intel's = manuals for details. >=20 > Thanks, > Brian >=20 >>>=20 >>> Thanks! >>>=20 >>> Jeff >>>=20 >>> *=E5=8F=91=E4=BB=B6=E4=BA=BA: *Paulo Alcantara = >>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: *2017=E5=B9=B411=E6=9C=8814=E6=97= =A521:23 >>> *=E6=94=B6=E4=BB=B6=E4=BA=BA: *edk2-devel@lists.01.org = >>> *=E6=8A=84=E9=80=81: *Rick Bramley ; = Laszlo Ersek ; Andrew Fish = ; Eric Dong >>> *=E4=B8=BB=E9=A2=98: *Re: [edk2] [RFC 0/1] Stack trace support in = X64 exception handling >>>=20 >>> Hi, >>>=20 >>> On 14/11/2017 10:47, Paulo Alcantara wrote: >>>> Hi, >>>>=20 >>>> This series adds stack trace support during a X64 CPU exception. >>>>=20 >>>> Informations like back trace, stack contents and image module names >>>> (that were part of the call stack) will be dumped out. >>>>=20 >>>> 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. >>>>=20 >>>> What do you think guys? >>>>=20 >>>> BTW, I've tested this only with OVMF (X64 only), using: >>>> - gcc-6.3.0, GCC5, NOOPT >>>>=20 >>>> Any other tests would be really appreciable. >>>=20 >>> I've attached a file to show you how the trace would look like. >>>=20 >>> Thanks! >>> Paulo >>>=20 >>>>=20 >>>> Thanks! >>>> Paulo >>>>=20 >>>> Repo: https://github.com/pcacjr/edk2.git >>>> Branch: stacktrace_x64 >>>>=20 >>>> Cc: Rick Bramley >>>> Cc: Andrew Fish >>>> Cc: Eric Dong >>>> Cc: Laszlo Ersek >>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>> Signed-off-by: Paulo Alcantara >>>> --- >>>>=20 >>>> Paulo Alcantara (1): >>>> UefiCpuPkg/CpuExceptionHandlerLib/X64: Add stack trace support >>>>=20 >>>> = UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | = 344 +++++++++++++++++++- >>>> 1 file changed, 342 insertions(+), 2 deletions(-) >>>>=20 >>>=20 >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >=20 >=20 > --=20 >=20 > Brian >=20 > -------------------------------------------------------------------- >=20 > "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 > https://lists.01.org/mailman/listinfo/edk2-devel =