similar to: [LLVMdev] [lld][RFC] TargetLayout class removing

Good point. But I suggest to do that by two steps. First, remove TargetLayout and rename DefaultLayout to TargetLayout. Second, merge TargetLayout and Layout. The first step is easy, the second step generates large diff, requires reviewing etc. On Fri, Apr 3, 2015 at 10:40 PM, Rui Ueyama <ruiu at google.com> wrote: > I'm wondering if we even need TargetLayout. > > DefaultLayout

Hi, Now lld writes relocations to the ".rela" sections only. Mips requires to use the "rel" format. So we need to be able to select format and names of relocation section, names of symbols like __rela_iplt_* / __rel_iplt_*, dynamic table tag DT_RELA / DT_REL. My current idea: - Add two virtual functions DefaultLayout::createDynamicRelocationTable() and

Hi, Thanks a lot for your answer. It seems lld is still the best solution, even if it does not work "right out of the box" for us today. We already have a solution for the "objcopy" part (added the required output format to llvm-objdump). The ScriptLayout class seems to be empty for now (on the master branch at least), but we do not need linker scripts today. All that is

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

Hi Michael, On 9/16/2013 7:23 PM, Michael Spencer wrote: > Debug info linking is currently broken due to how we handle reading and > laying out non SHF_ALLOC sections. I posted a patch that partially fixes > this, but it's both the wrong approach and doesn't handle multiple input > files with debug info (wrong relocation values). > > The first issue is representing non

I had a similar issue with arm vs thumb in mach-o. Each function’s thumbness is marked in its symbol table entry. But it is even worse, a function could change encoding in the middle (only hand coded assembly could do this). My solution was to add a new Reference Kind for mach-o which is the current instruction encoding. The offsetInAtom() is the offset where the encoding kind changes.

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

Hi, Is it OK to use llvm-mc in the lld test suite? I do not want to maintain assembler, object and test files for small MIPS target related test. Instead of that I prefer to keep a single test file with assembler code and test suite instructions. Is it acceptable way? -- Simon Atanasyan

STO_MIPS16 and STO_MICROMIPS flags denote that the symbol use a different "compressed" instructions encoding. Both these flags can be combined with usual "visibility" flags. It looks like adding new flag into the contentTypes set might solve the problem. Thanks for the idea. I try to implement it. On Thu, Nov 6, 2014 at 6:52 PM, Shankar Easwaran <shankare at

On Mon, Sep 16, 2013 at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Michael, > > > On 9/16/2013 7:23 PM, Michael Spencer wrote: > >> Debug info linking is currently broken due to how we handle reading and >> laying out non SHF_ALLOC sections. I posted a patch that partially fixes >> this, but it's both the wrong approach and

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

On Mon, Dec 8, 2014 at 8:39 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > On 12/8/2014 11:09 AM, Joerg Sonnenberger wrote: >> >> On Mon, Dec 08, 2014 at 10:21:49AM -0600, Shankar Easwaran wrote: >>> >>> The DT_INIT/DT_FINI correspond to one initializer function,where as >>> DT_INIT_ARRAY/DT_FINI_ARRAY is used when there is more than one

Hi, On MIPS st_other field in the ELF symbols table might contain some additional MIPS-specific flags besides visibility ones. These flags should be copied to the output linked file. If YAML => Native conversion is switched off, there is no problem. But in case of the conversion we lose st_other field values. So I need an advice how to keep this information. Is it a good idea to extend YAML

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 Nov 11, 2014, at 11:54 AM, Rui Ueyama <ruiu at google.com> wrote: > This falls into the usual topic that whether or not we should have a generic map attached to an atom. You used a reference as an alternative for the map in this case but the basic idea is the same. > > Although using a reference would be practical, it still feels a hack to me. It's awkward at least. Why

On Wed, Apr 2, 2014 at 7:47 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I am not sure if you looked at this thread > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066155.html) > > let me know if you still have questions. > > As a short summary, we dont verify the architecture of files that are being > read. We could very well be passed in a

I think the linking context should decide whether to use rel (or) rela. This is also needed if --emit-relocations option is chosen (or) -r option is used. Thoughts ? Sent from my iPhone > On Jan 19, 2014, at 15:01, Simon Atanasyan <simon at atanasyan.com> wrote: > > Hi, > > Now lld writes relocations to the ".rela" sections only. Mips requires > to use the

On Mon, Dec 8, 2014 at 10:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The dynamic loader handles only one entry for DT_INIT. If there is more than > one init option, we could convert this as an .init_array instead ? > > If that doesnot work, we can come up with a .init_array option but I am not > sure about how will you handle priority with init_array's ?

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