search for: apoch

On Wed, Jul 27, 2016 at 12:06 AM, Johan Wehrli <johan.wehrli at strong.codes> wrote: > > Most of the time, it is a path problem: > https://support.microsoft.com/en-us/kb/3035999 > > If you open the file cmake/config-ix.cmake you will find the place where > cmake check if the DIA_SDK is present (there is also a note saying that > sometime this is a Windows bug). > >

...e front-end supplies sane metadata to the LLVM layer. My question to the list - is this work valuable for anyone else? Would there be general interest in documentation or even example code that assembles what I've learned throughout this effort? Thanks, - Mike [0] - https://github.com/apoch/epoch-language/wiki/Knowledge-Dump---Debugging-Epoch-Programs -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160724/b87c5fe2/attachment.html>

Hi Mike, > I'll check into that again. I ran across llvm-pdbdump earlier but couldn't get it to build on a vanilla 3.8 install (CMake is convinced I don't have the DIA SDK and I haven't found a way to change its mind). I have experienced something similar with the DIA SDK. Most of the time, it is a path problem: https://support.microsoft.com/en-us/kb/3035999

On Tue, Jul 26, 2016 at 8:02 AM, Reid Kleckner <rnk at google.com> wrote: > We've been pursuing the direction of writing PDBs from scratch in > llvm/lib/DebugInfo/PDB/Raw and related directories. It might be interesting > to have code that talks to MSPDB140.dll in LLVM, but we really want LLD to > be able to produce its output on any platform. > I completely agree

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 >

On Tue, Jul 26, 2016 at 12:30 PM, Zachary Turner <zturner at google.com> wrote: > I wrote most of the pdb code in llvm so far. As Reid suggested, if you > look in DebugInfo/PDB/Raw there is a significant amount of code dealing > with msf files and raw pdb streams. If you build the llvm-pdbdump tool you > can run it with the "raw" subcommand to dump lots of low level

It's not a solution to the actual bug (which is, as the thread you linked discusses, a problem with the assumption on LLVM's part that the __chkstk function lies within 2GB of the emitted code's address space) but there is a simple workaround: hoist all allocas to the first basic block of your function. This allows the JIT to perform all stack allocations in a single adjustment of the

I have a significant chunk of notes from my experience with garbage collector integration with LLVM that I'd be happy to contribute to this effort. The original notes live here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme I imagine it would be preferred if that document was formatted and edited to match the existing efforts; I'll try and start converting it over

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a c...

Hi, I'm using LLVM to convert expressions to native assembly, the problem is when LLVM compiles this code: define void @fn_0000000000000000(i8*, i8*, i8*) { bb: %res = alloca i32 %3 = load i32* %res %4 = bitcast i8* %0 to i32* %5 = load i32* %4 %6 = bitcast i8* %0 to i32* %7 = load i32* %6 %8 = xor i32 %5, %7 store volatile i32 %8, i32* %res %9 = load i32* %res %10 = icmp

Hi Philip, Thanks for your great list of ideas for the document! I don't really have a scope for the document beyond: If it something that requires mapping from high-level to LLVM IR, I think it should go into the document. I started out using C++ examples because many people know C++. I am personally mostly an advocate of statically checked languages but I don't see that as a reason

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

Hi all, I've been using the llvm.gcroot intrinsic combined with the generated machine stack maps to attempt to do precise GC without the use of a shadow stack. (This is all research work on a novel language so I have no existing system to compare against, for the record.) Most of my test suite is working and tracing stack roots correctly. However, there seem to be some scenarios where the

Hi all, I've been working recently on a precise garbage collector which runs alongside native code JITted by LLVM. Today marks the first time the GC has passed its entire test suite as well as extensive soak tests in non-trivial programs. It's been an interesting and educational process, to say the least, and I've run into quite a few things that might be useful to know for others