From: "Andrew Fish" <afish@apple.com>
To: Mike Kinney <michael.d.kinney@intel.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
"Ni, Ray" <ray.ni@intel.com>, Rebecca Cran <rebecca@bsdio.com>
Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
Date: Thu, 18 May 2023 10:22:49 -0700 [thread overview]
Message-ID: <1098DEB5-028F-46F2-8CF8-A965E8401F88@apple.com> (raw)
In-Reply-To: <CO1PR11MB492923BABB0D3D433E4EDB87D27F9@CO1PR11MB4929.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 5224 bytes --]
Yea, but I think you want static and volatile on the global. But good idea as for the non XIP case you can just modify the global. It might be a good idea to document the debugging flow in the header for CpuDeadLoop()...
Thanks,
Andrew Fish
> On May 18, 2023, at 10:19 AM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:
>
> Andrew,
>
> This might work for XIP. Set non const global to initial value that is expected value to stay in dead loop.
>
> UINTN mDeadLoopCount = 0;
>
> VOID
> CpuDeadLoop(
> VOID
> )
> {
> while (mDeadLoopCount == 0) {
> CpuPause();
> }
> }
>
> When deadloop is entered, developer can not change value of mDeadLoopCount, but they can use debugger to force exit loop and return from function.
>
> Mike
>
>
> From: Andrew (EFI) Fish <afish@apple.com>
> Sent: Thursday, May 18, 2023 10:09 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Ni, Ray <ray.ni@intel.com>; Rebecca Cran <rebecca@bsdio.com>
> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>
> Mike,
>
> Good point, that is why we are using the stack ….
>
> The only other thing I can think of is to pass the address of Index to some inline assembler, or an asm no op function, to give it a side effect the compiler can’t resolve.
>
> Thanks,
>
> Andrew Fish
>
>
> On May 18, 2023, at 10:05 AM, Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>> wrote:
>
> Static global will not work for XIP
>
> Mike
>
> From: Andrew (EFI) Fish <afish@apple.com <mailto:afish@apple.com>>
> Sent: Thursday, May 18, 2023 9:49 AM
> To: edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>; Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>>
> Cc: Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>; Rebecca Cran <rebecca@bsdio.com <mailto:rebecca@bsdio.com>>
> Subject: Re: [edk2-devel] CpuDeadLoop() is optimized by compiler
>
> Mike,
>
> I pinged some compiler experts to see if our code is correct, or if the compiler has an issue. Seems to be trending compiler issue right now, but I’ve NOT gotten feedback from anyone on the spec committee yet.
>
> If we move Index to a static global that would likely work around the compiler issue.
>
> Thanks,
>
> Andrew Fish
>
>
>
> On May 18, 2023, at 8:36 AM, Michael D Kinney <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>> wrote:
>
> Hi Ray,
>
> So the code generated does deadloop, but is just not easy to resume from as we have been able to do in the past.
>
> We use CpuDeadloop() for 2 purposes. One is a terminal condition with no reason to ever continue.
>
> The 2nd is a debug aide for developers to halt the system at a specific location and then continue from that point, usually with a debugger, to step through code to an area to evaluate unexpected behavior.
>
> We may have to do a NASM implementation of CpuDeadloop() to make sure it meets both use cases.
>
> Mike
>
> From: Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> Sent: Thursday, May 18, 2023 3:00 AM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com <mailto:michael.d.kinney@intel.com>>; Rebecca Cran <rebecca@bsdio.com <mailto:rebecca@bsdio.com>>; Ni, Ray <ray.ni@intel.com <mailto:ray.ni@intel.com>>
> Subject: CpuDeadLoop() is optimized by compiler
>
> Hi,
> Starting from certain version of Visual Studio C compiler (I don’t have the exact version. I am using VS2019), CpuDeadLoop is now optimized quite well by compiler.
>
> The optimization is so “good” that it becomes harder for developers to break out of the deadloop.
>
> I copied the assembly instructions as below for your reference.
> The compiler does not generate instructions that jump out of the loop when the Index is not zero.
> So in order to break out of the loop, developers need to:
> Manually adjust rsp by increasing 40
> Manually “ret”
>
> I am not sure if anyone has interest to re-write this function so that compiler can be “fooled” again.
> Thanks,
> Ray
>
> =======================
> ; Function compile flags: /Ogspy
> ; File e:\work\edk2\MdePkg\Library\BaseLib\CpuDeadLoop.c
> ; COMDAT CpuDeadLoop
> _TEXT SEGMENT
> Index$ = 48
> CpuDeadLoop PROC ; COMDAT
>
> ; 26 : {
>
> $LN12:
> 00000 48 83 ec 28 sub rsp, 40 ; 00000028H
>
> ; 27 : volatile UINTN Index;
> ; 28 :
> ; 29 : for (Index = 0; Index == 0;) {
>
> 00004 48 c7 44 24 30
> 00 00 00 00 mov QWORD PTR Index$[rsp], 0
> $LN10@CpuDeadLoo:
>
> ; 30 : CpuPause ();
>
> 0000d 48 8b 44 24 30 mov rax, QWORD PTR Index$[rsp]
> 00012 e8 00 00 00 00 call CpuPause
> 00017 eb f4 jmp SHORT $LN10@CpuDeadLoo
> CpuDeadLoop ENDP
> _TEXT ENDS
> END
>
>
>
[-- Attachment #2: Type: text/html, Size: 22617 bytes --]
next prev parent reply other threads:[~2023-05-18 17:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 9:59 CpuDeadLoop() is optimized by compiler Ni, Ray
2023-05-18 13:19 ` [edk2-devel] " Pedro Falcato
2023-05-18 15:36 ` Michael D Kinney
2023-05-18 16:49 ` [edk2-devel] " Andrew Fish
2023-05-18 17:05 ` Michael D Kinney
2023-05-18 17:08 ` Andrew Fish
2023-05-18 17:19 ` Michael D Kinney
2023-05-18 17:22 ` Andrew Fish [this message]
2023-05-18 17:24 ` Andrew Fish
2023-05-18 18:45 ` Andrew Fish
[not found] ` <17605136DCF3E084.26337@groups.io>
2023-05-18 20:45 ` Andrew Fish
2023-05-18 21:42 ` Michael D Kinney
2023-05-19 0:42 ` Andrew Fish
2023-05-19 2:53 ` Ni, Ray
2023-05-19 3:03 ` Jeff Fan
2023-05-19 15:31 ` Rebecca Cran
2023-05-19 16:31 ` Andrew Fish
2023-10-31 2:51 ` Ni, Ray
2023-10-31 3:37 ` Michael D Kinney
2023-10-31 8:30 ` Ni, Ray
2023-10-31 14:19 ` Michael D Kinney
2024-06-05 1:07 ` Michael D Kinney
2024-06-05 16:48 ` Oliver Smith-Denny
2024-06-07 16:57 ` Hernandez Miramontes, Jose Miguel
[not found] ` <1760952DCE55DF8D.29365@groups.io>
2023-05-19 16:09 ` Rebecca Cran
2023-05-18 17:36 ` Rebecca Cran
2023-05-18 18:21 ` Andrew Fish
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1098DEB5-028F-46F2-8CF8-A965E8401F88@apple.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox