This is an archive of the discontinued LLVM Phabricator instance.

[XCOFF] support writing sections, relocations and symbols for XCOFF64.
ClosedPublic

Authored by Esme on Mar 22 2022, 10:13 PM.

Details

Summary

This is the second patch to enable the XCOFF64 object writer.

Diff Detail

Event Timeline

Esme created this revision.Mar 22 2022, 10:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2022, 10:13 PM
Esme requested review of this revision.Mar 22 2022, 10:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 22 2022, 10:13 PM

My only real comment on this is patch ordering. An XCOFF/AIX person should review too.

llvm/lib/MC/XCOFFObjectWriter.cpp
749

The non-zero value plus "not supported yet" comment doesn't quite work. Perhaps "Only source file symbol supported"?

808–809

I'd have thought implementing the symbol table before relocations makes more sense.

847–850

Same comment as above: support the symtab first?

Esme updated this revision to Diff 418899.EditedMar 29 2022, 9:17 AM
Esme retitled this revision from [XCOFF][2/3] support writing sections and relocations for XCOFF64. to [XCOFF] support writing sections, relocations and symbols for XCOFF64..
Esme edited the summary of this revision. (Show Details)

Thanks for your comments! @jhenderson
It seems inappropriate to support the symbol table before the sections and relocations, due to their offset order, or some other reasons. So I enabled all these fields in this patch and also modified related test cases.

DiggerLin added inline comments.Mar 29 2022, 9:27 AM
llvm/lib/MC/XCOFFObjectWriter.cpp
196

I do not think we will change ".file" . change to const StringRef SourceFileName = ".file" ?

751

SymbolTableEntryCount+1 for ".file" symbol.

808–809

agree with James

llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
82

I am not sure, whether I understand correct or not ?

  1. fixup_ppc_half16ds: A 14-bit fixup corresponding to lo16(_foo) with implied 2 zero bits for instrs like 'std'.
  2. fixup_ppc_half16dq: A 16-bit fixup corresponding to lo16(_foo) with implied 3 zero bits for instrs like 'lxv'.
  3. fixup_ppc_half16 : A 16-bit fixup corresponding to lo16(_foo) or ha16(_foo) for instrs like 'li' or 'addis'.

in the https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-object-file-format#XCOFF__sua3i125jbau
r_rsize: 0x3F(6 bits)
Specifies the bit length of the relocatable reference minus one. The current architecture allows for fields of up to 32 bits (XCOFF32) or 64 bits (XCOFF64) to be relocated.

so for the
case PPC::fixup_ppc_half16ds:

{XCOFF::RelocationType::R_TOC, EncodedSignednessIndicator | 13 }
Esme updated this revision to Diff 419044.Mar 29 2022, 9:53 PM

Addressed @DiggerLin 's comments.

llvm/lib/MC/XCOFFObjectWriter.cpp
196

If the file auxiliary entry is not used, the symbol name is the name of the source file. If the file auxiliary entry is used, then the symbol name should be .file, and the first file auxiliary entry (by convention) contains the source file name.

Our current approach is to write a symbol without the auxiliary entry, with .file as the source file's name, but in fact we should write a symbol with the real source file's name. And we commented a todo for this.

// FIXME: add the real source file's name.

So I think the SourceFileName may be changed.

751
void XCOFFObjectWriter::assignAddressesAndIndices(const MCAsmLayout &Layout) {
  // The first symbol table entry (at index 0) is for the file name.
  uint32_t SymbolTableIndex = 1;
...
  SymbolTableEntryCount = SymbolTableIndex;
}

The ".file" symbol has been counted.

808–809

Thanks, since it's hard to separate the symbol table and relocation into 2 patches, I prefer to enable both of them in this patch.

llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
82

Thanks for your catch!

Nothing much else to add apart from a stylistic comment.

llvm/test/CodeGen/PowerPC/aix-extern-weak.ll
2–3 ↗(On Diff #419044)

I have a personal preference for this syntax: from the first line, it makes it clear that the next line is a new command, whilst from the second line, the indentation followed by an executable name makes it clear that this is a continuation of the previous line.

Same applies elsewhere.

Esme updated this revision to Diff 419333.Mar 30 2022, 11:26 PM

Improved the format of run lines in tests.

DiggerLin added inline comments.Mar 31 2022, 8:46 AM
llvm/lib/MC/XCOFFObjectWriter.cpp
196

thanks.

713

maybe this is more readable , even there is duplication code of writeWord(NumberOfRelocEnt);

if (!is64Bit()) {
     W.OS.write_zeros(4); // Reserved
     writeWord(NumberOfRelocEnt);
     W.OS.write_zeros(6); // Reserved
  else {
     writeWord(NumberOfRelocEnt);
     W.OS.write_zeros(1); // Reserved
     W.write<uint8_t>(XCOFF::AUX_SECT);
  }
751

thanks.

llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
82

PPC::fixup_ppc_half16dq: is a A 16-bit fixup corresponding to lo16(_foo) with implied 3 zero bits for instrs like 'lxv'.
for PPC::fixup_ppc_half16dq
it should be
{XCOFF::RelocationType::R_TOC, EncodedSignednessIndicator | 15 } ?

DiggerLin added inline comments.Mar 31 2022, 10:54 AM
llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
82

I am not a expert on the relocation, I just put my question and we may be need someone who is expert on the relocation to review the code.

Esme added inline comments.Apr 1 2022, 12:07 AM
llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
82
/// A 16-bit fixup corresponding to lo16(_foo) with implied 3 zero bits for
/// instrs like 'lxv'. Produces the same relocation as fixup_ppc_half16ds.
PPC::fixup_ppc_half16dq

Thanks, I thinks I need more investigation about this, the comment says it produces the same relocation as fixup_ppc_half16ds.

Esme updated this revision to Diff 423334.Apr 17 2022, 10:13 PM

Hi @DiggerLin, Sorry for the late update, I have verified that the SignAndSize value should be 15 for both fixup_ppc_half16ds and fixup_ppc_half16dq. Although there are zeros being implied, the totally size should be a 16-bit fixup. I confirmed this by testing LIT and test-suite, and the test-suite passes only if the value is 15, otherwise there will be an error like this

Relocation overflow in reference to: L..CPI168_7 (entry 3199)
        Address: 0x00082c12; RLD type: R_TOC; RLD length: 14
jhenderson added inline comments.Apr 19 2022, 12:49 AM
llvm/test/CodeGen/PowerPC/basic-toc-data-def.ll
4–10

FWIW, I'd actually keep the old style here, as it makes it clear which commands the options apply to, whilst still indicating FileCheck is a continuation. Same applies in similar cases.

Looks almost good to me. Thanks for adding this support.

llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
74

Is it possible to add some tests to verify the new relocation types added here for 64-bit objects, especially the ones the existing case changes do not contain?

82

Hmm, yes, I also think this is a little confuse. From 64bit OpenPower ABI, section 3.5.1, it says:

In the following figure, half16ds is similar to half16, but is really just 14 bits because the two least significant bits must be zero and are not really part of the field. (Used by, for example, the ldu instruction.) In addition to the use of this relocation field with the DS forms, half16ds relocations are also used in conjunction with DQ forms. In those instances, the linker and assembler collaborate to create valid DQ forms. They raise an error if the specified offset does not meet the constraints of a valid DQ instruction form displacement.

I think it clearly indicates that fixup_ppc_half16ds and fixup_ppc_half16dq should use same relocation infos.

For the bit length, it does not give a clear answer, it says is similar to half16, but is really just 14 bits. I checked the source code of commercial XLC, it gives 15. So I think it should be good to use 15 here.

84

Should we handle RelocationType::R_TOCU? I guess it may be generated in large code model(-mcmodel=large).

llvm/test/CodeGen/PowerPC/aix-extern-weak.ll
351 ↗(On Diff #423334)

Use relative index like above Index: [[#Index+25]]?

llvm/test/CodeGen/PowerPC/aix-extern.ll
480 ↗(On Diff #423334)

Same here.

Esme updated this revision to Diff 425411.Apr 26 2022, 9:09 PM

Addressed comments and improved tests.

llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
84

fixup_ppc_half16ds and fixup_ppc_half16dq may only correspond to lo16 of instrs, not ha16, so we shouldn't deal with RelocationType::R_TOCU here.

I have added the corresponding large code model test in llvm/test/CodeGen/PowerPC/aix-xcoff-reloc-large.ll.

Esme added inline comments.Apr 26 2022, 9:12 PM
llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
74

Tests in ppc64-abs-reloc.s, aix-xcoff-reloc.ll, aix-xcoff-reloc-large.ll etc. cover the new relocation types.

shchenz added inline comments.Apr 27 2022, 7:25 PM
llvm/lib/Target/PowerPC/MCTargetDesc/PPCXCOFFObjectWriter.cpp
84

Yes, right. When large code model is in effect, the higher 16 bit is relocated by addis which will not use fixup kind fixup_ppc_half16dq or fixup_ppc_half16ds

llvm/test/CodeGen/PowerPC/aix-available-externally-linkage.ll
50 ↗(On Diff #425411)

Except this field Auxiliary Type, all other fields for the symbol table are the same with XCOFF32, should we reuse them? I prefer to reuse them as we can get a better view about the difference between XCOFF32/XCOFF64.

And many others test files too.

llvm/test/MC/PowerPC/ppc64-abs-reloc.s
4 ↗(On Diff #425411)

triple should be 64 bit.

27 ↗(On Diff #425411)

Exactly the same with above checks, can we reuse?

DiggerLin added inline comments.May 2 2022, 10:10 AM
llvm/lib/MC/XCOFFObjectWriter.cpp
713

I think we also need a test case for dwarf 64 too.

Esme updated this revision to Diff 427266.May 5 2022, 4:03 AM
  1. Simplify tests.
  2. Test dwarf64.
shchenz accepted this revision as: shchenz.May 12 2022, 9:59 PM

LGTM! Thanks for adding this amazing support.

Maybe we can wait for some days in case @DiggerLin or @jhenderson has some further comments.

This revision is now accepted and ready to land.May 12 2022, 9:59 PM
jhenderson accepted this revision.May 13 2022, 1:15 AM

Actually, according to the pre-merge checks, one of the tests is failing, and I suspect it might be related to this patch?

Esme updated this revision to Diff 429632.May 16 2022, 12:49 AM

Rebase.
Clean the failure in test llvm/test/CodeGen/PowerPC/aix-xcoff-visibility.ll.