Address comment -- use fixup_ppc_nofixup instead of FK_NONE to tie the ref symbol.

Add a Fixup of kind FK_NONE to later record a relocation of type R_REF.

Address comment.

Thanks for fixing the failure. The changes LGTM.

Please include as much context as possible with your diff. https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

Rebase.
LIT, LNT and Bootstrap are clean.

Addressed comments.

Addressed comments.
Changed the Fixup Value for TOC direct external symbols and added test lines for it in toc-data-const.ll.

Addressed comments and verified the materialization results.
However, I can't find a proper instruction to turn 0xABCD ADDD ABCD ADDD into 0xABCD ABCD ABCD ADDD, ie. modify Lo16OfHi32 (bits 32...47), so I didn't handle the pattern like 0xABCD ABCD ABCD ADDD.

Addressed comments except for the FixupValue for external TOC data.

ping

Addressed comments.
Didn't find a better way instead of looping through to find the corresponding overflow section.

Address comments.

LGTM. Thanks!

LGTM. Thx.

LGTM. Thank you for fixing it.

Addressed comments. Thanks @DiggerLin and @shchenz

Btw. Do you have any plans to implement an option like "--loader-section" to embrace all this loader section related information?

Feel sorry that i'm just getting started to review this patch.
I've applied the patch and test the functionality and it looks good overall. Thanks.
However, considering the printing format of relocations in llvm-readobj, when --expand-relocs is not specified, we usually print relocations in this format:

vaddr     section    type   symbol
20000294    2       POS   .data
2000029c    2       POS   0

Only when --expand-relocs is specified, we print relocations like the format in this patch.
The --dyn-relocations option also follows such rule.

Update the comments.

Hi @DiggerLin, thank you for your review. I'm also confused by the description from the doc, if my understanding is correct, according to the doc, the FixedValue will ignore the value of Fixup.getOffset(), because the address of the csect containing the branch instruction to be modified equals to SectionMap[ParentSec]->Address + Layout.getFragmentOffset(Fragment). This is obviously incorrect. I have tested LNT and bootstrap for this patch under the options of -fintegrated-as -ffunction-sections, and both are clean.

In D137819#3970056, @jhenderson wrote:

I'm okay with an NFC reformatting patch if it's needed, rather than trying to bundle together the changes in with functional changes.

Addressed comments.

Rebase on latest commit.

FYI. I committed an NFC patch rG664cbfaf07e0 to format this patch.

In D137819#3953495, @DiggerLin wrote:

In D137819#3939790, @Esme wrote:

In D137819#3925955, @DiggerLin wrote:

change the description to 'support the relocation overflow section."

As the doc says, the overflow section is required when either of the relocation entries or the line number entries exceeds 65,534. As long as one of the counts exceeds 65,534, the other one will also be set to 65535 in the primary section header, and then the overflow section will record actual counts for both relocation entries and line number entries, where the s_paddr for relocation entries and s_vaddr for line number entries.
Therefore I reckon there's no need to identify whether it's a relocation overflow section or line number overflow section.

if one day, you want to add the functionality patch of overflow section for line number , what title  you want to use for that new patch?

Addressed comments.

In D137819#3925955, @DiggerLin wrote:

change the description to 'support the relocation overflow section."

Addressed comments.
Thx @hubert.reinterpretcast and @DiggerLin

Addressed comments.
Thx @DiggerLin

Clean test failure.

Sorry for the late reply, in fact I'm not quite sure about using the existing --dyn-syms option or adding an XCOFF specific one, so I wait to see what others think.
I noticed that the objdump from AIX system tool kits prints the loader section (together with its symbols and relocations) with the XCOFF specific option -P loader:

In D131873#3881526, @shchenz wrote:

Compared with previous versions, to me, seems some valid transformations are gone now because of the new bail out case Subtarget.isPPC64() && Opc == PPC::CMPWI. Maybe we can have a further check why PPC64 generates CMPWI 0 for some cases. For these cases, I guess CMPDI 0 should also be ok, so that there will be more record form opportunities here. But we can do that in another patch.

Update comments.

The bootstrap test is clean.

The symbols in the loader section should be the dynamic symbols in the general definition, so is it possible to use the original option --dyn-syms, and then implement the defined interface XCOFFDumper::printDynamicSymbols()?

LGTM. Thanks for your work.

Apologize for the late update due to some compiler-rt errors occurred. I'm working on fixing it.

LGTM. Thx!