similar to: [elf2] How to support both big and little endian MIPS targets

Hi, I am working on support R_MIPS_HI16 / R_MIPS_LO16 in the new LLD and have a couple of questions. == Q1 In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses combined addend (AHI << 16) + (short)ALO where AHI is original R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16 relocation [1]. There are two

On Sat, Nov 21, 2015 at 9:28 AM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Nov 20, 2015 at 10:13 PM, Simon Atanasyan <simon at atanasyan.com> > wrote: >> >> In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 >> relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses >> combined addend (AHI << 16) + (short)ALO where AHI is

On Sat, Nov 21, 2015 at 10:08 AM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Nov 20, 2015 at 11:02 PM, Simon Atanasyan <simon at atanasyan.com> > wrote: >> >> On Sat, Nov 21, 2015 at 9:28 AM, Rui Ueyama <ruiu at google.com> wrote: >> > On Fri, Nov 20, 2015 at 10:13 PM, Simon Atanasyan <simon at atanasyan.com> >> > wrote: >>

Hi, There are more than one MIPS relocations which need GOT entry creation. Let's consider two of them R_MIPS_GOT16 and R_MIPS_CALL16 [1]. R_MIPS_GOT16 is applicable to local and external symbols and performs a different calculation in each cases [2]. R_MIPS_CALL16 is applicable to external symbols only and a linker should show an error if it finds R_MIPS_CALL16 with a local target. Now LLD

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, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work

Hi Galina, I will try to find owners of these buildbots. I hope to get results on the next week. On Sat, Nov 3, 2018 at 1:48 AM Daniel Sanders <daniel_l_sanders at apple.com> wrote: > > Hi Galina, > > I'm sad that they appear to have been abandoned but no objections from me as I'm not the admin for any of these anymore. A couple of them were taken over by a colleague

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.

Hi, Sorry for delay with reply. It looks like now thunks can be implemented as a synthetic sections. In that case we give flexible solution and will be able to put thunks before/after related sections, using different alignment etc. As far as I know BFD linker uses the same approach at least for MIPS thunks. I will try to implement this idea. On Thu, Sep 8, 2016 at 1:44 AM, Rui Ueyama <ruiu

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

Let's suppose that MCLinker folks are here already - I am a committer of this project :). Maybe I did not formulate my suggestion correctly. When I offer to "install" the yaml2obj and obj2yaml utilities I mean result of the "make install" command only. I do not suggest to include this utilities into any distributed binary packages. To be clear I attached the patch with

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

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

On Wed, Sep 17, 2014 at 10:14 PM, Simon Atanasyan <simon at atanasyan.com> wrote: > Hi, > > Probably you get the error because you try to build LLVM in the source > code directory. Create a separate folder, cd to this folder and run > the configure script. > > $ mkdir llvm-bld > $ cd llvm-bld > $ ../<llvm src>/configure --enable-targets=mips > $ make >

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

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

Initial issue is related to R_MIPS_GPREL16/32 relocations. When we calculate such relocations we need to know _gp symbol's value. This value might come from different sources. Usually we setup it using constant offset from the .got section. Also it might be defined by a linker script. And in rare but possible case it comes from .reginfo / .MIPS.options sections. Got example, GNU bfd linker

Sure. One thing I want to remind you is that there is a place in Writer.cpp where we assume all synthetic sections were appended to end of Sections list. Look for `llvm::reverse`. If you add synthetic section thunks right before/after non-synthetic sections, you also want to change that. On Tue, Nov 29, 2016 at 1:18 PM, Simon Atanasyan <simon at atanasyan.com> wrote: > Hi, > >

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