similar to: Status of stack walking in LLVM on Win64?

 > These is metadata for epilogues (UWOP_EPILOG) but it is only available on Windows 8.1 and newer. I'm aware of this. I believe it is so sampling profilers can walk the kernel stack including through paged code -- i.e. the epilogue data is not paged, while the related epilogue code might be. Do you see it used, i.e. in usermode?  (where the pdata/xdata/code are all equally paged). It

For JITs it would appear that there is a patch needed for some kind of relocations. https://llvm.org/bugs/show_bug.cgi?id=24233 Is the patch really needed? What does it do? I'm not an expert here so asking. On Sun, Jul 3, 2016 at 2:48 AM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Sat, Jul 2, 2016 at 5:22 PM, Michael Lewis via llvm-dev >

Hi all, I'm developing a novel language that has historically used LLVM for code generation, behind a custom self-hosted front-end. The runtime for this language offers a garbage collector. In the past I've been on 32-bit Windows where precise garbage collection is relatively straightforward (as long as FPO is disabled). Walking the stack is a simple bit of pointer chasing and some

I've always just hacked support for this in to the various JITs (for JuliaLang, in our debuginfo.cpp file), by setting the no-frame-pointer-optim flag in the IR, then creating and populating a dummy unwind description object in the .text section, and registering that dynamically. Some day I hope to actually just register the .pdata/.xdata sections with the unwinder. PDBs are a bit different

Can we accept the patch which makes this work? There is a patch in the bug report for the MCJIT case. I'm confused why AOT and MCJIT case would be different but without it the information isn't registered. On Wed, Jul 6, 2016 at 9:07 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If you want an AOT linker and you don't want to use link.exe, you can use

Hi Rui, Peter, You know I'm enabling the "clang-cl + lld-link" toolchain for Uefi firmware. I meet a problem that the lld-link fails to link 32bits assembly functions, but can link 64bits assembly functions successfully. I need your suggestion. Below is an example to show my problem in linux. The example has two only source files: main.c and foo.nasm. $ cat main.c void Foo (void);

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

Thanks for the additional information. Right now I’m experimenting with a mix of code compiled with MSVC and code compiled with clang, trying to get a C++ exception thrown and caught by the MSVC-compiled code across a function in the clang-compiled code. My goal here is to isolate a small part of what needs to be done in a way that lends itself to tinkering. I think this might lead me to the

Here is our proposal to extend/enhance the x86-64 compact unwind descriptors to fully describe the prologue/epilogue for asynchronous unwinding.  I believe there are missing/lacking CFI directives as well, but I'll save that for another thread. Asynchronous Compact Unwind Descriptors Ron Brender, VMS Software, Inc. Revised January 25, 2018 1  Introduction This document proposes means to

+LLVMdev On Aug 4, 2012, at 9:45 AM, João Matos wrote: > Charles Davis did a lot of work on Win64 SEH support in LLVM, check commits r131652-r132880. > > As I haven't tested it yet, what exactly is broken? It's not finished yet. All the stuff for assembly code that uses Win64 EH is done, but not the code-gen-side stuff (cf. Win64Exception class in CodeGen). I was about to

Hi Reid, I’ve been following your proposal, and I’d be interested in helping out if I can. My main interest right now is in enabling C++ exception handling in clang for native (i.e. not mingw/cygwin) Windows targets (both 32-bit and 64-bit), but if I understand things correctly that will be closely related to your SEH work under the hood. I’m still trying to get up to speed on what is and is

I don’t really have a good enough feeling for the landingpad syntax yet to comment on the most natural way to extend it yet, but creating a synthetic cleanup function to call from the personality function is what I was thinking. With the current (trunk +/- a couple of weeks) clang, compiling for an “x86_64-pc-windows-msvc” target, I’m seeing a landingpad that looks like this: lpad:

Hello, I'm working on a binary translator project that emits an .ll file. I'm trying to debug it in Visual Studio and would like to be able to step through and see my generated .ll file in the debugger. Does LLVM support debug information corresponding to an input .ll file? My hunch is "no, as it expects debug info to come from Clang." I assemble it using: llc -filetype=obj

Hi Nick, It is a pleasure to be in contact with the creator of the compact unwind approach! I can see how an array of 32-bit unwind blocks could be used to describe each distinct point within a function (within a prolog in particular). But then you end up with six or seven or more such blocks for a large percentage of functions, don't you? Seems like a lot of additional space for something

Thanks all - looks like RuntimeDyldCOFFX86_64 is indeed the missing link. I'm temporarily using my own code to relocate the pdata section during linking (for unrelated reasons) but I'll definitely explore the dynamic loader in more detail. I'd much prefer to use well-tested code over my sloppy 20 minute hack job :-) -------------- next part -------------- An HTML attachment was

John and Ron, I developed the original compact unwind implementation for macOS 10.6 back in 2009. I tried to leave space in the design to support finer grain exception handling such as for asynchronous or for the shrink wrap optimization. The idea I had at the time was instead of having just one 32-bit compact unwind info per function, there could be an array of them each covering a different

Hi In my project I am still getting crashes on Windows - these seem to occur intermittently when there is a longjmp that crosses the boundary from C code over JITed code. I posted regarding this issue previously: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084919.html I was wondering if the support for stack unwinding on Win64 is now improved in LLVM - and if there are any particular

Does LLVM compile on ARM windows machines? More importantly, can LLVM generate code on Windows ARM? And lastly can it be hosted on Windows ARM so as to act like a JIT compiler for ARM?

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 John & Ron, I read through the proposal and had a couple of quick observations. 1. The proposed encoding assumes that the epilogue instructions always come at the end of the function -- or rather, just before the next function. If there is a stack protector __stack_chk_fail sequence, or there is NOP padding between functions, then the epilogue cannot be expressed. The proposed encoding