similar to: FunctionPass failing with undefined symbol

I am learning to write LLVM pass by trying to reproduce [hello world][1] example. The pass `hello.cpp` looks like: #include "llvm/Pass.h" #include "llvm/IR/Function.h" #include "llvm/Support/raw_ostream.h" using namespace llvm; namespace { struct Hello : public FunctionPass { static char ID; Hello() : FunctionPass(ID) {}

With shared libraries, it is always possible that you end up running with a different set of libraries than you actually linked with. However, how often is that actually the case? It seems at the very least there should be an option to tell the user that unless they switch libraries, their code won't be runnable. In most cases, everything is available to the linker to detect the situation

I have a test case where lld-5.0 fails to detect an undefined symbol (this bug also happens with clang/lld 4.0). I haven't narrowed down exactly all the circumstances when this can occur, but in this case it was for a virtual method in a class defined in a shared library. If I build the executable with the raw object files, the linker notices the missing method (see test1 vs test2). This

Hopefully the right list … otherwise pointers appreciated (I’ve spent days trying to find a solution but could not find sufficient documentation, could not find a proper list of -flavor darwin commands) I am setting up an environment for cross compiling shared libraries using LLVM. Overall this works perfectly for many unix like environments but MacOS is a pain in the ass despite that I am

LLD work on Darwin is stalled out at the moment. Patches are welcome (and I'll try to find time to review them), but I'd recommend ld64 for any real-world linking. - Lang. On Thu, Apr 27, 2017 at 11:06 AM, Rui Ueyama <ruiu at google.com> wrote: > Cc'ing people who are working on macOS. > > On Thu, Apr 27, 2017 at 9:05 AM, Peter Kriens via llvm-dev < > llvm-dev

Cc'ing people who are working on macOS. On Thu, Apr 27, 2017 at 9:05 AM, Peter Kriens via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hopefully the right list … otherwise pointers appreciated (I’ve spent days > trying to find a solution but could not find sufficient documentation, > could not find a proper list of -flavor darwin commands) > > I am setting up an

Thanks for the answer. However, this means I need a different linker for MacOS as for Windows/Linux? I guess it is a not a major thing but I was hoping to set up a cross compile env. where only the header files and shared libraries differed :-( I guess we’re not there yet … :-) Kind regards, Peter Kriens > On 6 May 2017, at 19:57, Lang Hames <lhames at gmail.com> wrote: > >

Lang - I think there has perhaps been a regression in that case, because I have an example of a trivial IR module that fails to be linked correctly: https://bugs.llvm.org/show_bug.cgi?id=32376 Kevin provided some clues about this but I was not able to find a fix. On Tue, May 16, 2017 at 12:24 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Guys, > > As I left it, lld on Darwin

Sounds like a fantastic goal, and enticingly close … Kind regards, Peter Kriens > On 11 May 2017, at 20:53, Andrew Kelley <superjoe30 at gmail.com> wrote: > > Zig author here in the same boat. Looks like I'm going to have to disable cross compiling for MacOS and when compiling native for MacOS add a dependency on the system linker. Really looking forward to Mach-O support

Hi Devang, You recently mentioned that the pass manager now allows a ModulePass to require a FunctionPass. I just tried it but ran into errors. Could you please take a look to see if I did anything wrong? Thanks! Basically I changed the HelloWorld sample pass to be a ModulePass and tried to use the LoopInfo pass inside the runOnModule routine. See below for the source code and error messages.

Hi, all: I wanted to use a FunctionPass (e.g. *MemoryDependenceAnalysis*) in a ModulePass, and then I used the method "getAnalysis<* MemoryDependenceAnalysis*>(llvm::Function *)" described at http://llvm.org/docs/WritingAnLLVMPass.html#ModulePass to get the FunctionPass. But , it still crashed when I invoked this pass in tool 'opt'. However, if I change my pass to

Hello everyone, I am trying to write a trivial adding metadata transformation pass. I have Test.bc the target on which I want to perform transformations. First, I compile with clang++ my target program and I have my resulting Test.bc. I save it under Test1.bc. As a particular example, I have " %myDimension = alloca %class.ThreeDimension, align 4 ". Second, I apply my pass :

Hello, I am encountering a linking failure when using Control Flow Integrity while building a shared library. It looks like the wrong relocation type is being emitted for functions referenced via the PLT. I am using clang 3.9. The error message I get is: /usr/bin/ld.gold: error: /tmp/lto-llvm-df723d.o: requires dynamic R_X86_64_PC32 reloc against 'free' which may overflow at runtime;

Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. https://llvm.org/docs/SourceLevelDebugging.html discusses some of the debug info IR metadata in LLVM. On Fri, Feb 2, 2018 at 1:03 AM Ku Nanashi via llvm-dev < llvm-dev at lists.llvm.org> wrote:

> Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. Thank you for the comment! I don't know if this is a proper way to fix, but after I add DebugLoc same as inserting position instruction, no error occurs.

On Fri, Feb 27, 2009 at 4:50 PM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Fri, Feb 27, 2009 at 4:32 PM, Jay Foad <jay.foad at gmail.com> wrote: > >> >> Could you please rig Makefile.rules or something to print out the value >> >> of $(LLVM_ON_WIN32) ? The only way I can think of this happening is if >> >> that's

Hi, This is a question on how to resolve weak symbols from the binary for symbols that are also llvm::Module-local. Currently, the JIT seems to favor resolving to module-local symbols over existing symbols: $ cat symbols.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T

On Sun, Mar 1, 2009 at 4:24 AM, Nick Lewycky <nicholas at mxc.ca> wrote: Please try this patch. I tried to copy exactly what libtool would do on Cygwin by reading the libtool source. Hi Nick, Working fine on Cygwin :) Aaron Nick Aaron Gray wrote: On Fri, Feb 27, 2009 at 4:50 PM, Aaron Gray <aaronngray.lists at googlemail.com <mailto:aaronngray.lists at

Aaron Gray wrote: > On Sun, Mar 1, 2009 at 4:24 AM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Please try this patch. I tried to copy exactly what libtool would do > on Cygwin by reading the libtool source. > > > Hi Nick, > > Working fine on Cygwin :) Great to hear! I've committed the fix in r65922.

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but