similar to: [LLVMdev] Modeling ELF linker with lld/Chunks.

On Mon, Apr 20, 2015 at 1:44 AM, Shankar Easwaran <shankarke at gmail.com> wrote: > Attached patch fixes the issue. Thanks for the quick fix. The patch LGTM if you add a test case. Unfortunately yaml2obj does not support duplicated section names but we can use a binary input file. -- Simon Atanasyan

Nothing wrong with going ahead with a temporary measure if the temporary measure is reasonable (besides the discussion if checking in binary files is desirable). Even if you plan to add a test written in YAML, it's better to check in a binary at least for now than checking it in without any tests. On Mon, Apr 20, 2015 at 7:59 AM, Shankar Easwaram <shankarke at gmail.com> wrote: > I

Hi Nick, In addition to what you mentioned, I think there needs a special *AliasReference* that need to be created which the DefinedAtom points to. Thanks Shankar Easwaran -------- Original Message -------- Subject: Re: [PATCH] Add a fallback mechanism for undefined atom. Date: Thu, 29 Aug 2013 15:15:49 -0700 From: kledzik at apple.com <kledzik at apple.com> Reply-To:

Hi Nick, This would work only if an alias is another name for the same symbol(weak symbols). If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work. I was thinking to model this for ELF for the below functionalities :- a) __wrap For example : --wrap fn What I plan to do here is, create a undefined function fn atom create a defined

Can an “alias” atom just be a zero sized atom with one reference of kindLayoutBefore to its target? The layout engine should then place the alias atom right before the real atom, so you wind up with two symbols at one address. -Nick On Sep 12, 2013, at 3:02 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > In addition to what you mentioned, I think there

Hi, FYI LLD cannot handle ELF sections with non-unique names. An object file with such sections can be generated by the Clang since r234143. I am not sure that Clang works absolutely correct but bfd linker works fine. Right now I do not have a time to investigate this problem. If nobody take, I will try to solve it later. Here is the reproduction script for x86_64 host: $ cat test.cc template

Hi Nick, I need the original path of the files, from where the atoms were parsed. The path for the atoms are completely useless after the round trip pass. This is needed to support linker scripts with the Gnu flavor. I think there are more uses too like diagnostics (relocation overflows etc) I was planning to add a patch so that the native writer, stores the original path for atoms Another

Hi, The round trip passes just tries to load a *complete* object file in YAML/Native format back. The internal state should be the complete object file in native/yaml format. If some state is not recorded and that is really needed in the writer, we should add that to the Atom model. Shankar Easwaran On 2/9/2015 1:29 PM, Rui Ueyama wrote: > I want to bring this again because I think

Not all input files have to be able to represented in YAML/Native format. There are many unrealistic use cases there. No one wants to write an executable file in Native because there's no operating system that can run that file. So is YAML. So is the combination of .so file and Native/YAML unless we have an operating system whose loader is able to loads a YAML .so file. We might want to write

On Wed, Jan 2, 2013 at 12:04 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > You might want to look at the ELFLayout changes to see what functionality is > missing from that. > > The ELFLayoutOptions has a hook into reading the Linker script which needs > to be implemented. So, looking into it a bit, I think that ELFLayoutOptions is not the right place to parse the

Hi Shankar, I almost implement ELFRelocationReader but still not completely sure that this is a right direction. Suppose somebody wants to override creation of the `ELFReference` object from the `Elf_Rela` or `Elf_Rel` record. Let's consider two implementations A and B: A: ===== 1. Factor out `ELFReference` creation from `createDefinedAtomAndAssignRelocations` into a couple of virtual

On Sep 13, 2013, at 3:35 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > This would work only if an alias is another name for the same symbol(weak symbols). I don’t know what that means. Can you clarify? > > If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work. That is the exact scenario I think it *will* work

I think no one is opposing the idea of reading and writing YAML. The problem here is that why we need to force all developers to write code to serialize intermediate data in the middle of link, which no one except the round-trip passes needs. On Fri, Feb 6, 2015 at 6:41 PM, Shankar Easwaram <shankarke at gmail.com> wrote: > Doing it for every input file is not useful as some of the

We are modeling target specific functionally using references, Doesn't your idea defeat the purpose of the atom model? Atoms are mostly target neutral and yaml/native format represents just an atom. Having a derived class for atoms will have a impact on the testing method with lld IMO. We could continue to model using references in my opinion and add some meta data information in the atom

On 1/6/2013 6:30 PM, Meador Inge wrote: > On Jan 6, 2013, at 2:05 PM, Sean Silva wrote: > >> but since the script can define symbols, it has to be parsed earlier. > It is more than just defining symbols. There are many other directives that > have command line option equivalents that are used to setup linking. You can pull symbols > with EXTERN, add other files to link with

On Wed, Jul 02, 2014 at 05:09:14PM -0700, Nick Kledzik wrote: > Shankar, Does lld for ELF support loading indirect DSOs? It doesn't, which is a bug. Joerg

On Jan 6, 2013, at 2:05 PM, Sean Silva wrote: > but since the script can define symbols, it has to be parsed earlier. It is more than just defining symbols. There are many other directives that have command line option equivalents that are used to setup linking. You can pull symbols with EXTERN, add other files to link with INPUT, add groups of archives to be searched with GROUP, name the

A bit off topic: ARM Group relocations define a logical set of consequent instructions to be relocated to form one single address. For such relocations a 1 to 1 relation is also met, so no need of special processing in applyRelocation. Concerning native format: it also introduced unneeded code complexity to me when I wanted to set calculated relocation addend back into the Reference object in the

Hi Nick, I am planning to work on adding support for definining expressions for the Gnu flavor. Currently Gnu ld supports an option --defsym symbol=expression. The expression may be composed of other symbols. Any symbol that appears in the expression, gets its value from the output symbol value (address of the symbol in the output file). In addition the symbol only gets defined if and only

On Fri, Aug 23, 2013 at 4:54 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Nick, > > Thanks for your reply. > > > On 8/23/2013 3:40 PM, Nick Kledzik wrote: > >> >> These are the changes I plan to make, and some questions that I have >> >> a) Define a new contentType for DefinedAtoms to say 'Expression' >> b) Create a