similar to: [LLVMdev] Advice on MachineMoves and SEH

On Jun 1, 2011, at 7:27 PM, Charles Davis wrote: > Hi, > > If you've been following llvm-commits, you might know that I've been > working on implementing support for SEH--specifically, the Win64 variant > of it--in LLVM. > > I know a lot of you couldn't care less about this, but I'd really > appreciate some advice about this. I'm almost to the point

On 11-06-02 6:56 AM, Anton Korobeynikov wrote: > Hi Chip, > >> Because of all this, it's hard to reconstruct the SEH information from >> the MachineMove array. I have thought about adding a new array specific >> to SEH information, but I'm not sure how you guys would feel about that. >> Any ideas on how to solve this problem? > Same problem with

On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote: > On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >> Hi Chip, >> >>> Because of all this, it's hard to reconstruct the SEH information from >>> the MachineMove array. I have thought about adding a new array specific >>> to SEH information, but I'm not sure how you guys would feel about

Hi Chip, > Because of all this, it's hard to reconstruct the SEH information from > the MachineMove array. I have thought about adding a new array specific > to SEH information, but I'm not sure how you guys would feel about that. > Any ideas on how to solve this problem? Same problem with ARM-specific EH. I ended with own information scheme, where instructions are marked as

On Jun 2, 2011, at 9:11 AM, Jim Grosbach wrote: > > On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote: > >> On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >>> Hi Chip, >>> >>>> Because of all this, it's hard to reconstruct the SEH information from >>>> the MachineMove array. I have thought about adding a new array specific

Hi Devang, > How many passes are there this late in chain ? In any case, they all know how to deal with PROLOG_LABEL anyway. Personally, I'd like to make dwarf writer free of MachineModuleInfo. Quite a lot. Especially on ARM where we have all sorts of expansion and transformation passes at MI level. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint

---------- Forwarded message ---------- From: Anton Korobeynikov <anton at korobeynikov.info> Date: Sun, Jun 5, 2011 at 11:20 Subject: Re: [LLVMdev] Advice on MachineMoves and SEH To: Charles Davis <cdavis at mymail.mines.edu> Chip, > Well, I've mulled it over for a while, and I've decided to take the ARM > EH approach of marking frame instructions and recognizing them

Hi, I'd like to submit a patch to match the clang patch on the front end. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140414/103257.html The front end doesn't need this patch to work but it's still important. This is mostly based on work done by kai from redstar.de Could I get some feedback on this? I'm not sure if the emitting of the register names will effect

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

On Oct 14, 2008, at 11:21 PM, Kenneth Boyd wrote: > Mark Kromis wrote: >> Resend >> >> >> On Oct 14, 2008, at 5:40 AM, Mark Kromis wrote: >> >> >>> Greetings, >>> >>> I have a compiler error that I have not been able to get through. I >>> usually depend upon pre-built binaries but there was none available >>> for

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,

I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it really necessary? I’m wondering if you can treat the cleanups and filter functions as portions of the same function, instead of outlining them to separate functions. Can you arrange to set up the base pointer on entry to

> On Nov 17, 2014, at 5:50 PM, Reid Kleckner <rnk at google.com> wrote: > > On Mon, Nov 17, 2014 at 5:22 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it

Hi, On 15.04.2014 23:44, Vadim Chugunov wrote: > Hi, > I am curious - how does clang deal with epilogue-less functions that > result from _Raise_Exception being marked 'noreturn'? > I've also been playing with Kai's patch, and discovered that this tends > to greatly confuse Windows stack unwinder in cases when noreturn call is > at the end of a function, so

Hi Jb, It's good to see someone step up and take a shot as this again. I dropped this because it seems to me it wasn't a high priority task for LLVM/Clang. Implementing SEH is more of LLVM work than Clang work. For 32-bit SEH, there are prologue/epilogue instruction sequence to emit, setting try-level ([ebp-4]), recovering EBP ([ebp-18h]), and all these can only happen in LLVM, not

> On Nov 18, 2014, at 11:07 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Nov 18, 2014 at 10:50 AM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > >> On Nov 17, 2014, at 5:50 PM, Reid Kleckner <rnk at google.com <mailto:rnk at google.com>> wrote: >> >> On Mon, Nov 17, 2014 at 5:22 PM, Bob

In summary we have no less than six patches required to support Win64 SEH MinGW. The first five could be committed after review and LGTM but the last one also requires Ray Donnelly approval. Please comment in the Phabricator so the comments would be kept in context. 'unreachable' trap http://reviews.llvm.org/D3417 Win64 SEH (LLVM) http://reviews.llvm.org/D3418 Win64 SEH (clang)

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 all, We're at the point in our port of OpenVMS to x86-64 that we're working on the unwind code.  The current ABI and the current codebase doesn't have enough support for true asynchronous unwinding from any point (most notably in the prologue/epilogue) in the code that OpenVMS needs.  We're working on a set of changes to the compact unwind information to handle the additional

> From: Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> > Emitting directives in the epilogue is hard because the directives > apply to all instructions after in program-counter order. So if you > have an epilogue in the middle of a function and emit CFI directives > saying the registers are back where they were then the unwinder will > think that applies to the