[PATCH] D84549: [XCOFF][AIX] Support relocation generation for large code model

[Jason Liu via Phabricator via llvm-commits]

jasonliu added inline comments.


================
Comment at: llvm/lib/MC/XCOFFObjectWriter.cpp:434
     // The FixedValue should be the TC entry offset from TOC-base.
     FixedValue = SectionMap[SymASec]->Address - TOCCsects.front().Address;
 
----------------
jasonliu wrote:
> DiggerLin wrote:
> > jasonliu wrote:
> > > DiggerLin wrote:
> > > > I am not sure whether I understand is correct or not ?
> > > > FixedValue of intructions
> > > > addis 3, L..C0 at u(2) . FixedValue should get the high 16bits of SectionMap[SymASec]->Address - TOCCsects.front().Address;
> > > > 
> > > > lwz 3, L..C0 at l(3) FixedValue should get the low 16bits of SectionMap[SymASec]->Address - TOCCsects.front().Address;
> > > > 
> > > > if I understand correct , the code need to change.
> > > > 
> > > > 
> > > > 
> > > Could you give an example that would generated non-0 FixedValue in TOCU position?
> > > The example (the test case I have below) I tried before, TOCU position always have 0 as its FixedValue with system assembler generated object.
> >   ```1ae98: 3c 62 00 01                   addis 3, 2, 1
> >                         0001ae9a:  R_TOCU       (idx: 36364) a10995[TE]
> >    1ae9c: 80 63 8d f8                   lwz 3, -29192(3)
> >                         0001ae9e:  R_TOCL       (idx: 36364) a10995[TE]
> >    1aea0: 90 83 00 00                   stw 4, 0(3)
> >    1aea4: 3c 62 00 01                   addis 3, 2, 1
> >                         0001aea6:  R_TOCU       (idx: 36366) a10996[TE]
> >    1aea8: 80 63 8d fc                   lwz 3, -29188(3)
> >                         0001aeaa:  R_TOCL       (idx: 36366) a10996[TE]
> >    1aeac: 90 83 00 00                   stw 4, 0(3)
> >    1aeb0: 3c 62 00 01                   addis 3, 2, 1
> > ```
> It seems the system as would generate a non-0 FixedValue for you when your TOC region is larger than 64KB.
> But xlclang (which do not use system as to generate object) would always generate 0 for the TOCU region, and linker would know how to change the fix-up '0' to the proper value that points to the correct TOC entry.
Some update on this:
I talked with people from AIX OS team, and it seems indeed what we put in the TOCU's fix-up region does not matter for the linker. 
But aside from that, I think our current logic for TOCL region might not work well when we overflow the initial TOC region, because we might need to wrap around the value in that case. For example, we would need to put 0 in TOCL region when it's the first TOC entry in the second TOC region. 
And since we are not able to produce that case yet (we have a report_fatal_error somewhere else that would get triggered before this one because we haven't figured out a plan on how to deal with "minus" offset TOC entries in small code model mode.), I will report a fatal error here as well to remind us when we run into this issue in the future. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84549/new/

https://reviews.llvm.org/D84549