similar to: [LLVMdev] [lld] Handling ELF section groups/.gnu.linkonce sections.

On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: > I am trying to implement support for handling section groups in lld. > > There are two ways of figuring out section groups with ELF. > > a) Sections with SHF_GROUP property > b) .gnu.linkonce sections (the signature identified by the name of the section) -- This was the method to coalesce similiar constants. > >

On 10/30/2013 12:53 AM, Nick Kledzik wrote: > On Oct 29, 2013, at 9:52 PM, Shankar Easwaran wrote: >> I am trying to implement support for handling section groups in lld. >> >> There are two ways of figuring out section groups with ELF. >> >> a) Sections with SHF_GROUP property >> b) .gnu.linkonce sections (the signature identified by the name of the section)

Hi Nick, Bigcheese, I wanted to add support to support .gnu.linkonce sections in the resolver. _*About .gnu.linkonce sections*_ .gnu.linkonce sections were primarily present in ELF that was used in a way to model COMDAT in early ELF implementations. We have seen usecases of .gnu.linkonce sections used in various object files(mainly libc), and I think its much needed to support this style in

So I was looking into handling ELF groups today in the Atom model. It appears that we will need to add the concept of a group to the atom model directly, as modeling it with references fails to capture some semantics. http://www.sco.com/developers/gabi/latest/ch4.sheader.html Groups in ELF are collections of sections that must be either included or excluded as a unit. They also are used to

On Wed, Dec 19, 2012 at 4:43 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: > >> So I was looking into handling ELF groups today in the Atom model. It >> appears that we will need to add the concept of a group to the atom >> model directly, as modeling it with references fails to capture some >>

On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: > So I was looking into handling ELF groups today in the Atom model. It > appears that we will need to add the concept of a group to the atom > model directly, as modeling it with references fails to capture some > semantics. > > http://www.sco.com/developers/gabi/latest/ch4.sheader.html > > Groups in ELF are

I support Nick's option too. I think handling groups is another example of using follow on references. One question is how does an atom outside the group refer to the main atom here ? Will not garbage collection cleanup the main atom/signature atom because there are no references ? Thanks - Shankar Easwaran On Wed, Dec 19, 2012 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote:

On Dec 19, 2012, at 4:53 PM, Michael Spencer wrote: > On Wed, Dec 19, 2012 at 4:43 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: >>> So I was looking into handling ELF groups today in the Atom model. It >>> appears that we will need to add the concept of a group to the atom >>> model

I'm using LLVM to compile one of the MYSQL libraries and then generate assembly using llc and compile that with gcc to create the lib and link with the rest of the system. I'm able to compile llc output with gcc without any problem. However, when I try to link the server with the library compiled with LLVM I get the following error during linking:

Hi, Currently lld ties up all atoms in a section for ELF together. This proposal just breaks it by handling it differently. *This requires **NO ELF ABI changes. *_*Definitions :-*_ A section is not considered safe if there is some code that appears to be present between function boundaries (or) optimizes sections to place data at the end or beginning of a section (that contains no symbol).

I think I share the goal with you to make the foundation for better dead-strip, so thank you for suggesting. I'm not sure if marking a section as a whole as "safe" or "unsafe" is the best approach, though. Some comments. - If the compiler generated code is always "safe", and if we can distinguish it from hand-written assembly code by checking if there's a

I've run into some issues with the current atom object model that I would like to fix. The current 4 atoms are not expressive enough. We need to be able to serialize a larger set of atoms, many of which are format specific. The set of common atoms (shared between all formats) should be the set that the resolver requires to work. SharedLibrary is not included in this (by looking at the source

On 7/25/2013 3:56 PM, Rui Ueyama wrote: > I think I share the goal with you to make the foundation for better > dead-strip, so thank you for suggesting. I'm not sure if marking a section > as a whole as "safe" or "unsafe" is the best approach, though. Some > comments. > > - If the compiler generated code is always "safe", and if we can >

On Jul 18, 2012, at 3:41 PM, Clow, Marshall wrote: > On Jul 18, 2012, at 2:34 PM, Nick Kledzik wrote: >> On Jul 18, 2012, at 12:52 PM, Michael Spencer wrote: >>> I've run into some issues with the current atom object model that I >>> would like to fix. >>> >>> The current 4 atoms are not expressive enough. We need to be able to >>>

Before I go writing a bug report, I want to know if the behavior I am seeing is intended. Before 1.3, I was able to generate a linkonce definition in one module, and an external declaration in another module and link them together, with the result being a defined symbol with external linkage. However, with the latest head, it apparently discards the linkonce version, and my output contains

Is there any reason -ffunction-sections and -fdata-sections wouldn't work? If it'll work, it may be be better to say "if you want to get a better linker output use these options", rather than defining new ELF section. On Thu, Jul 25, 2013 at 2:01 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > On 7/25/2013 3:56 PM, Rui Ueyama wrote: > >> I think I

Not all users compile their code with -ffunction-sections and -fdata-sections. This is to handle usecases when libraries use a mix of object files too. On 7/25/2013 4:10 PM, Rui Ueyama wrote: > Is there any reason -ffunction-sections and -fdata-sections wouldn't work? > If it'll work, it may be be better to say "if you want to get a better > linker output use these

http://llvm.org/docs/LangRef.html#linkage-types says: Globals with “linkonce” linkage are merged with other globals of the same name when linkage occurs. This can be used to implement some forms of inline functions, templates, or other code which must be generated in each translation unit that uses it, but where the body may be overridden with a more definitive definition later. Unreferenced

I'm working with a C++ code generator that produces multiple instances of the same definition (specifically, it generates explicit instantiations of the same template in multiple output source files). With the GNU ld, I'm able to link successfully using the --allow-multiple-definitions flag; however this flag is not supported in llvm-ld. Is there any way I can either convince llvm-ld to

On Tue, Oct 24, 2017 at 9:27 PM, Vedant Kumar <vsk at apple.com> wrote: > Unreferenced linkonce globals are allowed to be discarded. > > > Is __udivmodti4 referenced? > It's referenced by a different .o file, but nothing within the module. My confusion comes from the missing direct object in the sentence. Referenced by a function local to the module? Referenced by any