similar to: [LLVMdev] Handling ELF groups.

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

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 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:

Suppose i write // foo.cpp __attribute__((section(“foo”))) int x; // bar.cpp __attribute__((section(“foo”))) int y; And i compile and link these two object files together using lld. What assumptions can I make regarding alignment/padding between the two symbols? I’m comfortable getting an answer by reading the source, but that won’t tell if any properties i discover are guaranteed or just

Hi All, I have a design question of how your linker would be suitable for modeling ELF semantics. The ELF linker needs the functionality of reading relocations ahead of symbol resolution for the following usecases :- - Add linker defined symbols if there is a relocation to the symbol (Examples are : defsym, PROVIDE) - Dont halt the linker operation if there are undefined symbols but they are

Hi Nick, 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. Section Groups(SHF_GROUP) is the preferred way on ELF but .gnu.linkonce sections is

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)

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 Mon, May 11, 2015 at 11:13 AM, Rui Ueyama <ruiu at google.com> wrote: > If you attach two ore more symbols along with offsets to a chunk of data, > it would be a pretty similar to a section. That means that if you want to > do something on the atom model, now you have to treat the atoms like > sections. > What do you lose/pay by having to treat the atoms like sections?

"On Thu, Jun 4, 2020 at 3:11 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > + Ben Dunbobbin, whose name I take in vain below. > He's my local expert on weird ELF features. > > > -----Original Message----- > > From: David Blaikie <dblaikie at gmail.com> > > Sent: Thursday, June 4, 2020 2:43 PM > > To: Robinson, Paul

Hi Nick, Thanks for the reply. On 10/19/2012 5:18 PM, Nick Kledzik wrote: > > From the linker's perspective, if the directive was not used, it has to be more conservative it what it can do with the file. In particular it adds a "follow-on" reference from each atom in a section to the next one. The follow-on atoms constrain the layout engine that particular atoms must

Looks like it is also not working on x86_64, using clang/lld I am seeing a segmentation fault: Dump of assembler code for function _Z4funcj: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: push %rbx 0x0000000000400592 <+2>: push %rax 0x0000000000400593 <+3>: mov %edi,%ebp 0x0000000000400595 <+5>: pop %rdx 0x0000000000400596

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

Hello, I am attempting to merge 8 different data sets into a "grand merge" data set; all their variable names are common except for the the gas measured. However, when I did a quick stat summary comparison of merged data with unmerged data, it turned out that R mysteriously duplicated thousands of values in the merged set and I have no idea why. I've not had this problem with merge

Hi all, I am working with a spatial data set for which I am only interested in high concentration values ("leaks"). The low values (< 90th percentile) have already been turned into NA's, leaving me with a matrix like this: < CH4_leak lon lat CH4 1 -71.11954 42.35068 2.595834 2 -71.11954 42.35068 2.595688 3 NA NA NA 4 NA

Hi guys, After working for a long period of time on LLD, I think I found a few things that we should improve in the LLD design for both development ease and runtime performance. I would like to get feedback on this proposal. Thanks! *Problems with the current LLD architecture *The current LLD architecture has, in my opinion, two issues. *The atom model is not the best model for some architectures

I am tracking a problem with ThinLTO on Linux using gold and elf files where there is a disconnect between gold’s treatment of comdat groups and ThinLTO’s decisions about which weak references to convert to available externally. The net result is a definition is lost and a relocation entry is not handled. My status is summarized: https://bugs.llvm.org/show_bug.cgi?id=32980 Anyone familiar with

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 >>>

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).