similar to: The future of LLVM's C APIs: Notes and BoF.

Yup that is quite similar to my use case, but in addition I use LLVM to JIT as well from C using MCJIT. I have a patch for a DIBuilder binding, but it does change the API a bit, so depending on how this discussion goes, it can or cannot be added. It was necessary as the current binding wrap all metadata in values, which is very wasteful when dealing with a large amount of metadata. The breakage

> On 2014-Dec-05, at 00:39, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Thu, Dec 04, 2014 at 06:44:36PM -0800, Duncan P. N. Exon Smith wrote: >> As of Monday, I finally got a preliminary patch passing check and >> check-clang with the metadata-value split. > > Do you have the Go bindings enabled? Because of the changes you made to the > DIBuilder

> On Feb 5, 2017, at 7:13 PM, Rodney M. Bates via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > A couple of Modula-3 developers have worked on splicing LLVM on as an alternative > back end to the Modula-3 compiler, out-of-tree (the LLVM tree), of course. A major > portion of the necessary glue code is there, and at one time, I was able to get the > M3 compiler and the

Hi folks, Happy new year! Last LLVM Developers' Meeting I had a BoF: 'Raising Next Generation LLVM Developers'. It was suggested that we should update our open projects page and possibly restructure it a little bit. I volunteered to do this work and I need your help. Chandler and I started working on a google doc [1]. We pinged few code owners asking them to list of

In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one data member, a pointer to Metadata. If I try to make my C type a struct with one pointer, I can't cast it to DITypeRef. If I try to go inside the classes and use the pointer, I can cast, but can't construct a

I am, from a front end, calling functions like LLVMModuleCreateWithName, found in Core.h, ultimately calling LLVMWriteBitcodeToFile, found in BitWriter.h. Do I correctly presume, from the existence of LLVMDisposeModule, that I am responsible for calling it when I'm done? Will I need to do deeper disposing myself? I presume at least I will need to free strings I allocated myself, such as the

Before metadata was separated from values, I could create a debug info forward declaration and eventually resolve it using LLVMReplaceAllUsesWith in core.h. Now, I can't figure out how to resolve it. I can find no function that seems to do this. My one wild guess that giving the forward decl and the resolving decl the same UniqueId might do it is not working. I am currently using 3.6.1, but

On 07/25/2015 08:57 PM, Andrew Wilkins wrote: > On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: > > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one > data member, a

It's now a multi-stage process. First, there is a difference between a permanent forward declaration (i.e. the actual definition is in a different file) and a temporary forward declaration (i.e. it will appear later in the same file). To create a permanent forward declaration: DICompositeType *result = m_DIBuilder->createForwardDecl( dwarf::DW_TAG_structure_type,

> On 2015-Jul-25, at 15:44, Rodney M. Bates <rodney_bates at lcwb.coop> wrote: > > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one > data member, a pointer to Metadata. > > If I try to make my C type a struct with one pointer, I can't

On 08/03/2014 05:30 PM, Justin Bogner wrote: > "Rodney M. Bates" <rodney_bates at lcwb.coop> writes: >> I can build llvm 3.4.2 fine, using instructions in GettingStarted.html, >> and making assumptions to account for my using tar files instead of svn. >> Although I had downloaded and extracted both llvm-3.4.2.src.tar.gz and >> cfe-3.4.2.src.tar.gz, giving

On 07/27/2015 10:59 AM, Rodney M. Bates wrote: > > > On 07/25/2015 08:57 PM, Andrew Wilkins wrote: >> On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: >> >> In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap >> llvm::DITypeRef, declared in

On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop> wrote: > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a > way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class > with one > data member, a pointer to Metadata. > > If I try to make my C type a struct with one pointer, I can't

Have I correctly inferred below, how I build IR and debug info for a function type and a function (value), in particular, how to supply the names of the formal parameters? To create a function in llvm IR and give names to its formal parameters, I must: 1. Build a LLVMTypeRef for the type of each formal and the function result. 2. Build a function type using LLVMFunctionType, from the results of

George Karpenkov <ekarpenkov at apple.com> writes: > Should -DCMAKE_CXX_COMPILER be also specified? CMake is smart enough to infer that from C_COMPILER: % grep CMAKE_CXX_COMPILER CMakeCache.txt CMAKE_CXX_COMPILER:FILEPATH=/Users/bogner/llvm-lkgc/bin/clang++ >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <mail at justinbogner.com> wrote: >> >> (kcc, george:

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

I can build llvm 3.4.2 fine, using instructions in GettingStarted.html, and making assumptions to account for my using tar files instead of svn. Although I had downloaded and extracted both llvm-3.4.2.src.tar.gz and cfe-3.4.2.src.tar.gz, giving directories llvm-3.4.2.src and cfe-3.4.2.src, clang apparently did not get built. The only files with names starting with "clang" anywhere

(kcc, george: sorry for the re-send, the first was from a non-list email address) My configuration for building the fuzzers in the LLVM tree doesn't seem to work any more (possibly as of moving libFuzzer to compiler-rt, but there have been a few other changes in the last week or so that may be related). I'm building with a fresh top-of-tree clang and setting -DLLVM_USE_SANITIZER=Address

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>