https://devblogs.microsoft.com/oldnewthing/20220418-00/?p=106489 Skip to main content [RE1Mu3b] Microsoft The Old New Thing The Old New Thing The Old New Thing * Home * DevBlogs * Developer + Visual Studio + Visual Studio Code + Visual Studio for Mac + DevOps + Developer support + CSE Developer + Engineering@Microsoft + Azure SDK + IoT + Command Line + Perf and Diagnostics + Dr. International + Notification Hubs + Math in Office * Technology + DirectX + PIX + SurfaceDuo + Startups + Sustainable Engineering + Windows AI Platform * Languages + C++ + C# + F# + Visual Basic + TypeScript + PowerShell Community + PowerShell Team + Python + Q# + JavaScript + Java + Java Blog in Chinese * .NET + .NET + .NET MAUI + Blazor + ASP.NET + NuGet + Xamarin * Platform Development + #ifdef Windows + Apps for Windows + Azure Depth Platform + Azure Government + Bing Dev Center + Microsoft Edge Dev + Microsoft Azure + Microsoft 365 Developer + Old New Thing + Windows MIDI and Music dev + Windows Search Platform * Data Development + Azure Cosmos DB + Azure Data Studio + Azure SQL Database + OData + Revolutions R + SQL Server Data Tools * More [ ] Search Search Cancel The x86 architecture is the weirdo, part 2 [png] Raymond C April 18th, 2022 Some time ago I noted that The x86 architecture is the weirdo. (And by x86 I mean specifically x86-32.) I was reminded by the compiler folks of another significant place where the x86 architecture is different from all the others, and that's in how Windows structured exceptions are managed. On Windows, all the other architectures track exception handling by using unwind codes and other information declared as metadata. If you step through a function on any other architecture, you won't see any instructions related to exception handling. Only when an exception occurs does the system look up the instruction pointer in the exception-handling information in the metadata, and use that to decide what to do: Which exception handler should run? What objects need to be destructed? That sort of thing. But the x86 is the weirdo. On Windows, the x86 tracks exception information at runtime. When control enters a function that needs to deal with exceptions (either because it it wants to handle the exception, or just because it wants to run destructors when an exception is thrown out of the function), the code must create an entry in a linked list threaded through the stack and anchored by the value in fs:[0]. In the Microsoft Visual C++ implementation, the linked list node also contains an integer which represents the current progress through the function, and that integer is updated whenever there is a change to the list of objects requiring destruction. It is updated immediately after the construction of an object completes, and immediately before the destruction of an object commences. This special integer is a real pain in the neck, because the optimizer sees it as a dead store and really wants to optimize it out. Indeed sometimes, it really is a dead store, but sometimes it isn't. Consider: struct S { S(); ~S(); }; void f1(); void f2(); S g() { S s1; f1(); S s2; f2(); return S(); } The code generation for this function goes like this: struct ExceptionNode { ExceptionNode* next; int (__stdcall *handler)(PEXCEPTION_POINTERS); int state; }; S g() { // Create a new node ExceptionNode node; node.next = fs:[0]; node.handler = exception_handler_function; node.state = -1; // nothing needs to be destructed // Make it the new head of the linked list fs:[0] = &node; construct s1; node.state = 0; // s1 needs to be destructed f1(); construct s2; node.state = 1; // s1 and s2 need to be destructed f2(); construct return value; node.state = 2; // s1, s2, and return value need to be destructed node.state = 3; // s1 and return value need to be destructed destruct s2; node.state = 4; // return value needs to be destructed destruct s1; } The unwind state variable is updated whenever the list of "objects requiring destruction" changes. As far as the optimizer is concerned, all of these updates to state look like dead stores, since it seems that nobody reads them. Aha, but somebody does read them: The exception_handler_function. The problem is that the call to the exception_handler_function is invisible: It is called when an exception is thrown by the f1() or f2 () function, or by the destructor of the S objects.1 But wait, some of these really are dead stores. For example, the assignments of 2 to node.state is a dead store, because it is immediately followed by a store of 3, and there is nothing in between, so no exception could occur while the value is 2. Similarly, the store of 3 is dead because the destructor of S is implicitly noexcept.1 And the store of 4 is dead for the same reason: No exception can occur when destructing s1. Further dead store elimination becomes possible if f1 or f2 are changed to noexcept. So the optimizer is in a tricky spot here: It wants to eliminate dead stores, but the simple algorithm for identifying dead stores doesn't work here because of the potential for exceptions. Coroutines make this even worse: When a coroutine suspends, the exception-handling node needs to be copied from the stack into the coroutine frame, and then removed from the stack frame. And when the coroutine resumes, the state needs to be copied from the coroutine frame back into the stack, and linked into the chain of exception handlers. Knowing exactly when to do this unlinking and relinking is tricky, because you still have to catch exceptions that occur in await_suspend and store them in the promise. But we learned that await_suspend is fragile because the coroutine may have resumed and run to completion before await_suspend returns. void await_suspend(coroutine_handle<> handle) { arrange_for_resumption(handle); throw oops; // who catches this? } The language says that the thrown exception is caught by the coroutine framework, which calls promise.unhandled_exception(). But the promise may no longer exist! Dealing with all these crazy edge cases makes exception handling on x86, and particularly exception handling on x86 in coroutines, quite a complicated undertaking. Bonus reading: Zero-cost exceptions aren't zero cost. 1 Destructors default to noexcept if no members or base classes have potentially-throwing destructors, but you can mark your destructor as potentially-throwing,2 and then exceptions thrown from destructors become something the compiler has to worry about. 2 Please don't do that. [png] Raymond Chen Follow Tagged Code Read next Class template argument deduction may be the new hotness, but we'll always have maker functions It's all or nothing, and sometimes you don't have all. [png]Raymond C April 20, 2022 0 comment How do I access and customize the IInspectable methods of a Windows Runtime class written in C++/WinRT? Special access methods, but normal overrides. [png]Raymond C April 21, 2022 0 comment 2 comments Leave a commentCancel reply Log in to join the discussion. * [png] Hong Lou Tou April 18, 2022 7:17 pm collapse this comment But why does x86-32 exception handling have to work that way? Especially since x86-64 exception handling is table-based, like all the RISC architectures. Log in to Reply + [png] philiplu April 18, 2022 10:48 pm collapse this comment Table-based exception-handling metadata requires function prologue/epilogue sequences to have constrained forms that can be described by that metadata. When NT was first designed for x86-32, there was a lot of existing asm code that people wanted to easily port over to NT, and that ported code included pretty much every weird function entry/exit sequence you could think of (and lots more that you wouldn't imagine anyone would ever think of). Switching to table-based metadata would have required modifying all that code, making porting more difficult. At least, I assume that's the reasoning - I was deeply involved in the SEH runtime code in the '90s and '00s when I was on the VC++ compiler team. Log in to Reply Archive April 2022 March 2022 February 2022 January 2022 December 2021 November 2021 October 2021 September 2021 August 2021 July 2021 June 2021 May 2021 April 2021 March 2021 February 2021 January 2021 December 2020 November 2020 October 2020 September 2020 August 2020 July 2020 June 2020 May 2020 April 2020 March 2020 February 2020 January 2020 December 2019 November 2019 October 2019 September 2019 August 2019 July 2019 June 2019 May 2019 April 2019 March 2019 February 2019 January 2019 December 2018 November 2018 October 2018 September 2018 August 2018 July 2018 June 2018 May 2018 April 2018 March 2018 February 2018 January 2018 December 2017 November 2017 October 2017 September 2017 August 2017 July 2017 June 2017 May 2017 April 2017 March 2017 February 2017 January 2017 December 2016 November 2016 October 2016 September 2016 August 2016 July 2016 June 2016 May 2016 April 2016 March 2016 February 2016 January 2016 December 2015 November 2015 October 2015 September 2015 August 2015 July 2015 June 2015 May 2015 April 2015 March 2015 February 2015 January 2015 December 2014 November 2014 October 2014 September 2014 August 2014 July 2014 June 2014 May 2014 April 2014 March 2014 February 2014 January 2014 December 2013 November 2013 October 2013 September 2013 August 2013 July 2013 June 2013 May 2013 April 2013 March 2013 February 2013 January 2013 December 2012 November 2012 October 2012 September 2012 August 2012 July 2012 June 2012 May 2012 April 2012 March 2012 February 2012 January 2012 December 2011 November 2011 October 2011 September 2011 August 2011 July 2011 June 2011 May 2011 April 2011 March 2011 February 2011 January 2011 December 2010 November 2010 October 2010 September 2010 August 2010 July 2010 June 2010 May 2010 April 2010 March 2010 February 2010 January 2010 December 2009 November 2009 October 2009 September 2009 August 2009 July 2009 June 2009 May 2009 April 2009 March 2009 February 2009 January 2009 December 2008 November 2008 October 2008 September 2008 August 2008 July 2008 June 2008 May 2008 April 2008 March 2008 February 2008 January 2008 December 2007 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 May 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 Relevant Links I wrote a book Ground rules Disclaimers and such My necktie's Twitter Categories Code History Tips/Support Other Non-Computer Stay informed Login Insert/edit link Close Enter the destination URL URL [ ] Link Text [ ] [ ] Open link in a new tab Or link to existing content Search [ ] No search term specified. Showing recent items. Search or use up and down arrow keys to select an item. Cancel [Add Link] Code Block x Paste your code snippet [ ] Cancel Ok What's new * Surface Pro 8 * Surface Laptop Studio * Surface Pro X * Surface Go 3 * Surface Duo 2 * Surface Pro 7+ * Windows 11 apps * HoloLens 2 Microsoft Store * Account profile * Download Center * Microsoft Store support * Returns * Order tracking * Virtual workshops and training * Microsoft Store Promise * Flexible Payments Education * Microsoft in education * Devices for education * Microsoft Teams for Education * Microsoft 365 Education * Education consultation appointment * Educator training and development * Deals for students and parents * Azure for students Business * Microsoft Cloud * Microsoft Security * Azure * Dynamics 365 * Microsoft 365 * Microsoft Advertising * Microsoft Industry * Microsoft Teams Developer & IT * Developer Center * Documentation * Microsoft Learn * Microsoft Tech Community * Azure Marketplace * AppSource * Microsoft Power Platform * Visual Studio Company * Careers * About Microsoft * Company news * Privacy at Microsoft * Investors * Diversity and inclusion * Accessibility * Security English (United States) * Sitemap * Contact Microsoft * Privacy * Manage cookies * Terms of use * Trademarks * Safety & eco * About our ads * (c) Microsoft 2022