similar to: [LLVMdev] Appending linkage and DGE

On Thu, Dec 10, 2009 at 12:26 AM, Robin Sommer <robinsommer at web.de> wrote: > > On Sat, Dec 05, 2009 at 22:56 -0800, I wrote: > >> the LLVM documentation lists the 'appending' linkage for having the >> linker combine two arrays. I'm wondering though if it's then >> possible to get the size of the combined array, e.g., for iterating >> over

On Thu, Dec 10, 2009 at 2:05 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 10, 2009 at 12:26 AM, Robin Sommer <robinsommer at web.de> wrote: >> >> On Sat, Dec 05, 2009 at 22:56 -0800, I wrote: >> >>> the LLVM documentation lists the 'appending' linkage for having the >>> linker combine two arrays. I'm wondering

So, I was in the process of writing a custom LLVM pass (my first one, yay!) to handle the problem of measuring the length of an appending linkage array. The approach I was taking was pretty simple: Iterate through all of the module's global variables until I find one that is trying to calculate the end of an appending-linkage array, which looks like this: @_moduleListEnd = constant [1 x

This is an issue I raised a while ago, but I wanted to know if the situation had improved at all recently. The issue is determining the number of elements in an array that has appending linkage. The obvious course would be to use a constant GEP. Suppose we have N modules, each containing a global variable with appending linkage whose initializer is an array of size M containing elements of type

Hello. I'm posting this question here, because there seem to be no LLD-specific mailing list. Sorry in advance if this is wrong one. I compile two C source with following command: clang -flto -o %name.bc %name.c LLVM is augmented with my custom pass, which amongst other things create a global with appending linkage: @myvar = appending constant [1 x [1 x i8]*] ... I also have another pass

I think I finally understand how appending linkage type works and what it can be used for. What isn't obvious to me is how one gets the size of the resulting array. I'm thinking about using this to store bits of source language information and understand that it gets concatenated together by the linker. At both compile time and runtime, I want to be able to load an arbitrary bytecode

Talin wrote: > I'm trying to figure out how to do static initialization (like static > constructors in C++ or Java). I figured I would use appending linkage - > that is, for each module I'd generate a function that did all of the > static initialization for that module, and then I'd put a pointer to > that function in an array with appending linkage. Then my >

John Criswell wrote: > Talin wrote: > >> I'm trying to figure out how to do static initialization (like static >> constructors in C++ or Java). I figured I would use appending linkage - >> that is, for each module I'd generate a function that did all of the >> static initialization for that module, and then I'd put a pointer to >> that function in

I'm trying to figure out how to do static initialization (like static constructors in C++ or Java). I figured I would use appending linkage - that is, for each module I'd generate a function that did all of the static initialization for that module, and then I'd put a pointer to that function in an array with appending linkage. Then my compiler-generated startup code would simply

Can anyone explain how llc translates "appending linkage" global variables like llvm.global_ctors into assembly? In the case I am examining, the global_ctor variables are in multiple bitcode object modules produced by the llvm compiler as arrays of pointers. As documented, the arrays seem to be combined when the different bitcode object modules are linked into one, so now there is one

Hi all, the LLVM documentation lists the 'appending' linkage for having the linker combine two arrays. I'm wondering though if it's then possible to get the size of the combined array, e.g., for iterating over its elements? Or how would I otherwise use the combined array? Thanks, Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1

On Tue, Feb 18, 2020 at 9:42 PM David Blaikie <dblaikie at gmail.com> wrote: > I'm /guessing/ this might be related to the COFF support specifically > (perhaps COFF has no appending linkage support - in some cases LLVM IR > supports the union of all semantics so that different formats can be fully > expressed - but it means when targeting certain formats, some features are

On Sat, Dec 05, 2009 at 22:56 -0800, I wrote: > the LLVM documentation lists the 'appending' linkage for having the > linker combine two arrays. I'm wondering though if it's then > possible to get the size of the combined array, e.g., for iterating > over its elements? Or how would I otherwise use the combined array? Any thoughts on this? Am I missing something?

On 13 May 2016 at 08:51, Renato Golin <renato.golin at linaro.org> wrote: > On 13 May 2016 at 13:43, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: >> That means that appending linkage can only be used with llvm special >> symbols that never hit a real .o. > > So they should have been resolved by emission time, or it's a back-end error. Not resolved,

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

Append linkage is magical. It doesn't correspond to anything available in real object files (ELF/COFF/MachO). In those files sections are appended, but symbols are just resolved. That means that appending linkage can only be used with llvm special symbols that never hit a real .o. Long term I think we should delete it an replace with explicit use of section. But for now I would like to just

On Jan 30, 2011, at 8:36 PM, Talin wrote: > So, I spent the better part of a day making sure that each and every static global had a well-formed and unique name. So far so good. > > However, It turns out that what I need is a little different than what I described - I not only need to know which globals should be traced, but I also need to associate with each of these globals a data

My apologies for opening up an old thread, but I've been thinking about this quite a bit lately, and it seems to me that "appending linkage" would be a lot more useful in general if there was some way to determine the size of the appended array without having to write a custom pass to do it. In other words, using the standard llvm tools (llvm-link and friends), one ought to be

The problem I'm experiencing with Stacker has to do with linkage types (again!). What I'm trying to do is create a "global appending" array. In compilation units that don't include "main", I generate it with: TheStack = new GlobalVariable( /*type=*/ stack_type, /*isConstant=*/ false, /*Linkage=*/

> That's essentially what I did to get it to work but instead of > appending, I just opted for LinkOnce. Sounds ok. > > I don't quite understand why you need an appending global to do this, if you > > can only have one main. I would just set it to the correct initializer in the > > module that has main, and leave it external everywhere else. > > Its