similar to: [LLVMdev] Structured Exception Handling (SEH) on Windows

On Jun 3, 2009, at 18:50, Eli Friedman wrote: > On Wed, Jun 3, 2009 at 2:20 PM, Joe Ranieri<joe at alacatialabs.com> > wrote: >> Has any progress been made on structured exception handling on >> Windows? I saw a post by Duncan Sands back in September 2008, but >> haven't seen anything since. I'm trying to generate code to run on >> Windows, but would

On Wed, Jun 3, 2009 at 2:20 PM, Joe Ranieri<joe at alacatialabs.com> wrote: > Has any progress been made on structured exception handling on > Windows? I saw a post by Duncan Sands back in September 2008, but > haven't seen anything since. I'm trying to generate code to run on > Windows, but would really prefer not to ship libgcc... I fail to see the connection between

In the past people in #llvm suggested to me I should use landing pads instead of seh when it comes to Windows unless i really need seh. Looking at what gets generated win64 -gnu does use seh but calls the landing pad somehow, while win32 doesn't at all. It looks to me a custom win64 landing pad personality can also deal with things like Access Violation. Is there a way to make win32 also

Hi, I apologize if I'm posting this to the wrong list; if this is the case, please let me know. For some time now, I've been trying to get SEH exception handling to work in LLVM MCJIT (x64). While reading up on LLVM 3.8, I decided to pick it up again, because a lot has changed which simplifies things greatly. As a toy project, I'm attempting to catch an exception that's thrown

As stated in the design paragraph, this design does not intend to model precise CFG at instruction level since it’s complicated and unnecessary. As long as we comply C and C++ rules listed below, we achieve -EHa semantic. There is NO need to precisely model HW exception control flow at instruction-level. Your example about memcpy() is just a bug in current implementation. I will fix it so that

Resending; I accidentally dropped llvm-dev. -Eli From: Eli Friedman Sent: Wednesday, April 1, 2020 1:01 PM To: Ten Tzen <tentzen at microsoft.com> Cc: aaron.smith at microsoft.com Subject: RE: [EXT] [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling) This looks like it outlines the implementation pretty well. For goto in finally,

Hi, This is a spin-off of previous Windows SEH RFC below. This RFC only focus on supporting HW Exception Handling. A detailed implementation can be seen in here: https://github.com/tentzen/llvm-project/commit/8a2421c274b683051e456cbe12c177e3b934fb5e It passes all MSVC SEH suite (excluding those with “Jumping out of _finally” ( _Local_Unwind)). Thanks, --Ten **** The rules for C code: ****

I was wondering if the upcoming LLVM 3.5 release will have support for Microsoft Windows Structured Exception handling (e.g., __try/__except/__finally)? Thanks, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140730/e3d18989/attachment.html>

Hi, Eli, Why are you under the impression that threw_exception() will not be called if optimizations are enabled? I don’t know if the -EHa Spec is clearly described in MSFT Webs. At least this proposal has described the rules for both C & C++ code. The very first rule clearly said that “no exception can move in or out of _try region., i.e., no potential faulty instruction can be moved

Hi, all, The intend of this thread is to complete the support for Windows SEH. Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling. The document below is my proposed design and implementation to fully support SEH on LLVM. I have completely implemented this design on a branch in repo:

Hello all, I am trying to port some more code from windows 2000 to linux. The specific functionality I would like to port is called "Structured Exception Handling" and it works like so: 1. Define a function which based upons a signal throws an exceptoion. For example: void translateException(unsigned int u, EXCEPTION_POINTERS* pExp) { switch (u) { case (unsigned

Reply inline From: Ten Tzen <tentzen at microsoft.com> Sent: Wednesday, April 1, 2020 3:54 PM To: Eli Friedman <efriedma at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org> Cc: aaron.smith at microsoft.com Subject: [EXT] RE: [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling) ? For goto in finally, why are you

Hi, I'm getting: Unhandled exception at 0x00C211F0 in ConsoleApplication830.exe: 0xC00001A5: An invalid exception handler routine has been detected (parameters: 0x00000001). With some fairly simple SEH enabled routine: define i32 @__elements_entry_point_main(%._gt2a_RemObjects_d_Elements_d_System_d_Array_t_1s*) #0 personality i8* bitcast (i32 ()* @_elements_exception_handler to i8*) !dbg

* When a goto in a _finally occurs, we must "unwind" to the target code, not just "jump" to target label I'm not sure what you're trying to say here. In the Microsoft ABI, goto out of a catch block also calls into the unwinder. We have to run any destructors, and return from the funclet (catchret/cleanupret). * The call inside a _try is an invoke with EH

Indeed, it's 32bits x86 and there's no .safeseh or anything like it, even readobj -coff-load-config says nothing: File: ConsoleApplication830.exe Format: COFF-i386 Arch: i386 AddressSize: 32bit Now I know what to look for, thanks! On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote: > This is 32-bit x86, right? Sounds like the exception handler did not > appear in the /safeseh

Hi Chandler, Kai contributed the WIN64 SEH patch some time ago on llvm-commits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131118/196105.html it was never completed. Kai also responded in this thread. I opened a phabricator for the patch http://reviews.llvm.org/D3418 Yaron 2014-04-18 12:31 GMT+03:00 Chandler Carruth <chandlerc at google.com>: > > On Tue,

Can you clarify what you mean by "real SEH handling"? My company has me looking at this in the hopes that I can make LLVM capable of building windows drivers. If you mean "visual c++ style SEH", I'm fairly sure that isn't necessary for my purposes, but it would be nice. If you mean "something that works at all," then your concern about generalizing LLVM

Hi Chandler, There were five SEH releated patches posted in two threads in the last days. Two different patches in Martell e-mail starting this thread: the win64 seh (llvm) and the register names Three more related SEH patches in another thread: one for win64 seh clang, one for MinGW toolchain and another for unreachable prologue. To clarify and allow proper reviews for the different patches I

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at:

On Sat, Aug 15, 2020 at 8:39 PM Martin Storsjö <martin at martin.st> wrote: > Hi, > > > On Sat, 15 Aug 2020, Ivan Serdyuk wrote: > > > Just as Shoaib said, libunwind only is useful in environments > > that use > > the Itanium C++ ABI - there's really no use for it in an MSVC > > context > > (either using MSVC or