similar to: [LLVMdev] Proposal: "Fragile" Global References

I'm getting an error in the verifier after running a custom pass: Alias should have external or external weak linkage! This constraint isn't mentioned in the LangRef. According to the verifier code, the only permitted linkage types for a GlobalAlias are external, internal and weak. Why is that? The LangRef describes weak in terms of common, and common in terms of linkonce. Is

Hi, I’d like to make this proposal for extending the Constant hierarchy with a mechanism for introducing custom relocations in global initializers. This could also be seen as a first step towards adding a “bag-of-bytes with relocations” representation for global initializers. Problem In order to implement control flow integrity for indirect function calls, we would like to add a set of

So instead of using linkagetypes.weak I should use externalweaklinkage ? Le 11 févr. 2014 18:29, "Reid Kleckner" <rnk at google.com> a écrit : > You'd have to use extern_weak linkage. Clang compiles the foo declaration > to: > $ clang -cc1 -emit-llvm -o - t.c | grep declare.*@foo > declare extern_weak i32 @foo(...) #1 > > > > On Tue, Feb 11, 2014 at

Hi, I have a pass that creates a GlobalVariable, when I ran it get the following error: Global is external, but doesn't have external or weak linkage! i8** @myvar This is how I create the GlobalVariable: ------------------------------------------------ new llvm::GlobalVariable(*M, IRB.getInt8PtrTy(), false, llvm::GlobalValue::CommonLinkage, nullptr, "myvar", NULL,

I noticed that folding a cast of a global address to boolean doesn't work like I expected - there is a comment in the code that casts of external symbols should not happen, but I don't understand the rationale for this. // FIXME: When we support 'external weak' references, we have to prevent // this transformation from happening. In the meantime we avoid folding // any cast of

On 09/14/2017 10:31 PM, Daniel Neilson wrote: > > >> On Sep 14, 2017, at 9:30 PM, Hal Finkel <hfinkel at anl.gov >> <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 09/14/2017 10:43 AM, Daniel Neilson wrote: >>> Thank you for your thoughts, Hal. More information below... >>> >>>> On Sep 13, 2017, at 5:43 PM, Hal Finkel

> On Mar 11, 2016, at 9:56 AM, Reid Kleckner <rnk at google.com> wrote: > > On Fri, Mar 11, 2016 at 9:41 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote: > Okay, so, it sounds to me like LLVM basically treats strong definitions as protected, then. Should we just formalize that? > > I guess the proposal here would be: > 1.

Hey all, it's been a while since I have posted on llvm-dev, but that's mainly because I have been making good progress with my LLVM project. :) In any case, I'd like some advice on implementing my own version of appending linkage as a linker plugin. As I have pointed out on this list before, the existing appending linkage type isn't useful for me for two reasons: 1) There's

Thanks for your clear answer. Do you know what modifier should I use to declare such weak symbols in my llvm intermediate code? So that it can be compiled to the .o file with the weak attribute ? Le 10 févr. 2014 19:44, "Reid Kleckner" <rnk at google.com> a écrit : > COFF doesn't support the same kind of concept of 'weak' that ELF does. > This is the issue that

Hi all, I’ve most recently been grappling with a difficult to reproduce bug. I’ve traced the source of the difficulty in reproduction to the IVUsers analysis pass that is used by Loop Strength Reduction. Specifically, the IVUsers pass’s output is very sensitive to both the use list ordering of the instructions that it is looking at and the ordering of the Phi nodes in the header block of the loop

On Tue, 8 Mar 2016, Pete Batard via Syslinux wrote: > would. As I mentioned, I've seen reports of ISOHybrids that didn't boot in DD > mode, but that seemed to work using the Rufus process. And you will always be > limited by what the "automated process" that is the ISOHybrid algorithm can > do (which can of course be modified by a developer, but so can Rufus'

Hello, I'm generating C code (and the resulting obj files) using llvm 3.4 for both unix and windows. And I use the dreaded weak references, that, for windows, are not too widely supported. When I link my application on linux, I have no issue. But when I'm doing the same on windows using mingw I got a duplicate symbol error :

> That makes it fragile, and that’s why I disagree with your “90% done” assessment. > What if the service behing the hook is down for a few days? In the long-term view, a pretty trivial catch-up script ought to be able to synthesize a sane history after any amount of down-time. People could even run it locally for their bisecting needs if it was that important to them. In the short term, I

Hello, looking at Printer::doFinalization, I have some question about support of the different linkages. Here's a table of how that method handles the possible combinations: Initialized Null Internal .data, local .data, .comm, .local External .data, .globl .bss, .globl,

Hi Journeyer First, thank you so much for your updates on your experiments. I am currently following your steps but have found myself stuck with the following error: /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../../arm-linux-gnueabi/bin/ld: this linker was not configured to use sysroots clang: error: linker command failed with exit code 1 (use -v to see invocation) I used the command string you

Hi Scott, > So if I am looking at a CallInst, and want to know if the callee is > going to be instrumented by my pass, I can check F->isWeakForLinker(), > where F is the called function. But this just tells me when the > function definition *may* be replaced. I want to know precisely when > the CallInst is a call to a function that I am going to instrument as > part of my

> I'm sorry, I must be missing something here: > > In order to have weak linkage (I'm ignoring external weak for the moment) > a global has to be defined in the LLVM code. Because it is defined in the > LLVM code, it will have to be printed out by the target asm printer > somewhere. When that happens, it will get a .weak directive emitted for > it. It should, but

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Reid Kleckner" <rnk at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, November 29, 2016 11:34:56 AM > Subject: Re: [llvm-dev] RFC: Add an "interposible" linkage

Thanks for the comments! Responses below. Teresa On Tue, Jul 21, 2015 at 1:06 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-Jul-14, at 13:33, Teresa Johnson <tejohnson at google.com> wrote: > > > > As mentioned in the Updated ThinLTO RFC ( > http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), I am > sending the

Hi, I've been looking at improving atomicrmw & cmpxchg code more, particularly on architectures using the load-linked/store-conditional model. The summary is that current expansion for cmpxchg seems to happen too late for LLVM to make meaningful use of the opportunities it provides. I'd like to move it earlier and express it in terms of a first-class pair of "load linked"