similar to: [lld] R_MIPS_HI16 / R_MIPS_LO16 calculation

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

On Sun, Nov 22, 2015 at 1:28 AM, Rui Ueyama <ruiu at google.com> wrote: > I'm not sure if I understand the semantics of HI16 and LO16 relocations. If > my understanding is correct, a pair of HI16 and LO16 represents an addend > AHL. AHL is computed by (AHI<<16) | (ALO&0xFFFF). Can't we apply HI16 and > LO16 relocations separately and produce the same relocation

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat

What would be the best way to sort relocation entries before they are written out in ELFObjectWriter::WriteRelocationsFragment? According to the Mips ABI documents I have, there are certain restrictions on the order relocations appear in the table (e.g. R_MIPS_HI16 and R_MIPS_GOT16 must be followed immediately by a R_MIPS_LO16). When I enable post RA scheduling, some of the restrictions are

Hi Akira, If I follow correctly, the relocation entries can thus be in a different order than the instructions that they're for? That seems a bit odd, but I suppose there's nothing inherently wrong with that. It's just not something, AFAIK, that llvm has had to deal with before. This should definitely be a target-specific thing, not a general ELFObjectWriter thing, as other targets

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >

Hi Jim, Thanks for reviewing the patch. I couldn't get rid of STLExtras.h, but other than that, I followed all the suggestions in your email. Please let me know if you notice anything else that needs fixing. On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Akira, > > This is looking good. Some specific comments on the details below. > >

Hi Akira, Just two very minor things that I missed the first time around. 1. The 'fixup" member of ELFRelocation entry should be "Fixup" instead. 2. Since we're always passing in a non-NULL fixup, that should probably be a reference, not a pointer. Good for commit with those tweaks. Thanks! -Jim On Mar 23, 2012, at 1:07 PM, Akira Hatanaka wrote: > Hi Jim, >

(Adding just a bit to Jake's response) On Tue, Mar 26, 2019 at 11:31 AM Jake Ehrlich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Seiya, > > What should I prioritize? I suppose that improving llvm-objcopy is the >> most crucial work in this summer. > > > This is an opinion that will vary a lot from person to person. > +1! And don't forget that

Hi, I need to be able to use a special case list file containing thousands of entries (namely, a list of libc symbols, to be used when using DFSan with an uninstrumented libc). Initially I built the symbol list like this: fun:sym1=uninstrumented fun:sym2=uninstrumented fun:sym3=uninstrumented ... fun:sym6000=uninstrumented What I found was that, despite various bits of documentation [1,2], the

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

Hi, I need an advice how to support both big and little endian MIPS targets in the new LLD ELF design and escape code duplication. MIPS 32-bit big and little endian targets are very similar and differ in read/write functions. There are some options how to support both but I cannot make the best choice. 1. Make MipsTargetInfo a class template. Use the template's argument to select read/write

i trust i am still new in freebsd, after go through all mail and book, = now seem to be more close, i got 3 server and a notebook to play with, = install no problem. cvsup not problem.make buildworld not problem. make = build kernel become,every machine i got different error code 1,=20 1-one got system full=20 2-one showing this sometime=20 > anyone know the best way to be one time success,not

Hi I am running the following code: sym <- c(sym1,sym2,sym4) lifedxm <- c("O-BD","O-WELL","O-UNI") life <- c(lifedxm,lifedxm,lifedxm) tp <- c("TP-ANY","TP-ANY", "TP-ANY", "TP-SUB", "TP-SUB", "TP-SUB", "TP-CLIN" , "TP-CLIN", "TP-CLIN") data <-

Hi, I have a problem regarding sub-register definitions and LiveIntervals on our target. When a subregister is defined, other parts of the register are always left untouched - they are neither read or def:ed. It however seems that Codegen treats subregister definitions as somehow clobbering the whole register. The SSA-code looks like this after isel: (Reg0 and Reg1 are 16bit registers. Reg2,

Hi Quentin, On 08/15/14 19:01, Quentin Colombet wrote: [...] >> The question is: How should true subregister definitions be >> expressed so that they do not interfere with each other? See the >> detailed problem description below. > > We do have a limitation in our current liveness tracking for > sub-register. Therefore, I am not sure that is possible. > >

Hi, I'm having an issue with subregisters on my target. With a pseudo that writes to a 32 bit reg: %vreg20<def> = toHi16_low0_pseudo %vreg2; reg32:%vreg20 hi16:%vreg2 expands to %vreg2<def> = COPY %a2h; hi16:%vreg2 %vreg43<def> = mov 0, pred:0, pred:%noreg, %ac0<imp-use>, %ac1<imp-use>; lo16:%vreg43 %vreg20<def> =

Hi Quentin, On 08/19/14 18:58, Quentin Colombet wrote: [...] > It seems that you will have to debug further the *** Bad machine code: Instruction loads from dead spill slot *** before we can be of any help. Yes, I've done some more digging. Sorry for the long mail... I get: Inline spilling aN40_0_7:%vreg1954 [5000r,5056r:0)[5056r,5348r:1) 0 at 5000r 1 at 5056r At this point I have