similar to: [LLVMdev] [lld][ELF] How to transfer st_other field value from input to output file

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

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

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

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

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

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

On 9/23/2013 7:07 PM, Nick Kledzik wrote: > On Sep 23, 2013, at 4:52 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> The following code currently links incorrectly when linking against a dynamic libc on Ubuntu 12.10 unless -fpic is specified. >> >> #include <stdio.h> >> >> int main() { >> fputs("hi\n", stdout); >>

Hi Rui, Shankar, Do we really need empty TargetLayout class? No we have the following hierarchy: Layout <- DefaultLayout<> <- TargetLayout<> <- xxxTargetLayout<> I suggest to remove TargetLayout and rename DefaultLayout to TargetLayout. Thoughts? -- Simon Atanasyan

I'm not planning to remove YAML. YAML is important for testing. On Fri, Feb 6, 2015 at 3:57 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > I am fine with it. I hope you are not planning to remove YAML. > > > On 2/6/2015 4:54 PM, Rui Ueyama wrote: > > Can we remove Native format support? I'd like to get input from anyone who > wants to keep the

Can we remove Native format support? I'd like to get input from anyone who wants to keep the current Native format in LLD. On Thu, Feb 5, 2015 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > The only way currently is to create a new reference, unless we can think > of adding some target specific metadata information in the Atom model. > > This has come up

Hi, Thanks for the explanation. If I understand you properly you suggest to move relocation parsing to the class with the following interface. Right? Who will be user of this class? If it is still only ELFFile class, what benefits will we get from separation of this logic? template <class ELFT> class ELFRelocationReader { public: ELFRelocationReader(.....); // Returns all created

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, The LLD linker in gnu flavor mode accepts multiple -init/-fini command line options. For _all_ symbols specified by these options the linker creates appropriate entries in the .init_array/.fini_array sections. But it looks like LD and Gold linkers do not support this feature and take in account only the last -init/-fini options. % cat foo.c int a = 0; void foo() { a += 1; } void bar() { a +=

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 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 > initalizer function/finalizer function respectively. This is not true. The difference is that the DT_INIT / DT_FINI function is responsible for calling into the .init / .fini block and

Could you elaborate a bit about the issue that you are trying to solve with this suggestion? On Tue, Apr 1, 2014 at 9:27 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Nick, Bigcheese, > > Resurrecting a old thread. > > Now since we have a Registry that models Readers, do we want to have a > function in the Registry that evaluates whether a file should be