Page MenuHomePhabricator
Feed Advanced Search

Fri, Jun 14

peter.smith added a comment to D63333: [ELF][ARM] Merge handleARMTlsRelocation() into handleTlsRelocation().

I've got some stylistic suggestions; otherwise this looks to do the same thing as the previous code.

Fri, Jun 14, 8:06 AM · Restricted Project
peter.smith added a comment to D63191: [lld][ELF] Check length of subsection in .ARM.attributes.

would be to drop the size field to 0xFE, 0xFF, 0xFF, 0xFF.

This would cause problems on arm-be, no?

Fri, Jun 14, 6:23 AM · Restricted Project, lld
peter.smith added a comment to D63191: [lld][ELF] Check length of subsection in .ARM.attributes.

Strange, I haven't got notification. Are buildbot notifications working?
Anyway I think making Offset uint64_t instead of size_t will fix the issue.

Fri, Jun 14, 6:14 AM · Restricted Project, lld
peter.smith added a comment to D63191: [lld][ELF] Check length of subsection in .ARM.attributes.
I've not worked out why yet, it could be a 32/64-bit host issue.
Fri, Jun 14, 5:59 AM · Restricted Project, lld
peter.smith added a comment to D63191: [lld][ELF] Check length of subsection in .ARM.attributes.

Ironically bad-arm-attributes2.s test is failing on an Arm buildbot http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/4/steps/ninja%20check%201/logs/FAIL%3A%20lld%3A%3Abad-arm-attributes2.s

Fri, Jun 14, 5:56 AM · Restricted Project, lld

Thu, Jun 13

peter.smith added a comment to D63121: [ELF] Make the rule to create relative relocations in a writable section stricter.

I'll have a think to see if there are any other relocation types besides R_ARM_TARGET1 that LLD supports that can be made into a R_ARM_RELATIVE. I don't know PPC very well unfortunately. The other case I thought of that could be difficult is ILP32, where even on something like X86_64, or AArch64 the symbolic rel for a pointer would be the 32-bit relocation. I know LLD doesn't support the AArch64 ILP32 so this isn't a problem right now.

Thu, Jun 13, 2:45 AM · Restricted Project
peter.smith added a comment to D63121: [ELF] Make the rule to create relative relocations in a writable section stricter.

Was difficult to spot what was wrong with the bot as there were lots of commits and a non specific error message.

Thu, Jun 13, 2:27 AM · Restricted Project
peter.smith added a comment to D63244: Add --undefined-glob which is an --undefined with wildcard pattern match..

Looks good to me as well.

Thu, Jun 13, 1:35 AM · Restricted Project

Wed, Jun 12

peter.smith added inline comments to D63121: [ELF] Make the rule to create relative relocations in a writable section stricter.
Wed, Jun 12, 10:51 AM · Restricted Project
peter.smith added a comment to D63121: [ELF] Make the rule to create relative relocations in a writable section stricter.

Reproducer:
cat init.cpp

template <class T>
struct Bar {    
    T X;
    Bar(T X) : X(X) {}
};
Wed, Jun 12, 10:34 AM · Restricted Project
peter.smith added a comment to D63121: [ELF] Make the rule to create relative relocations in a writable section stricter.

A look at the differences between libclang.so with and without the patch is that what used to be a R_ARM_RELATIVE relocation is now a R_ARM_ABS32 relocation to an undefined symbol. The latter will likely resolve to 0. All of the difference is concentrated in the .init_array section which uses the R_ARM_TARGET1 relocation, which is treated as R_ARM_ABS32 by default but with an option be treated as R_ARM_REL32 (some embedded systems use offsets rather than addresses).
For example:
Good

Wed, Jun 12, 9:10 AM · Restricted Project
peter.smith added a comment to D63121: [ELF] Make the rule to create relative relocations in a writable section stricter.

This commit has caused the arm lld buildbot to fail. I can reproduce it on an Arm machine and a bisect found this one as the change. If I revert this change then the specific failure goes away. Unfortunately I can't tell you exactly what is wrong yet, the failure is in the libclang unit tests which are a shared object linked by LLD. I haven't yet had a chance to isolate the segfault and work out what is causing it. I'll keep looking to see if I can work out what specifically is wrong.

Wed, Jun 12, 7:14 AM · Restricted Project
peter.smith added a comment to D63190: Add -gnu-map option to emit a map file in the GNU-tsyle format..

I've been through to see if I could spot any significant differences. I've recorded what I found although I'm not sure how significant they are to the person attempting to parse the map file though.

Wed, Jun 12, 6:26 AM · Restricted Project
peter.smith added a comment to D63190: Add -gnu-map option to emit a map file in the GNU-tsyle format..

Not had a chance to go through the gold source yet to see if there is anything obviously missing. From a quick experiment using a linker-script derived from ld.bfd it seems like gold's map file remains much the same, whereas ld.bfd will give information about symbol resolution etc. Will take a look at the gold source this afternoon.

Wed, Jun 12, 3:46 AM · Restricted Project
peter.smith added a comment to D63190: Add -gnu-map option to emit a map file in the GNU-tsyle format..

Yes, we have an internal user who has a proprietary tool to process a -Map output. As to the difference between bfd and gold, they don't look too big, so perhaps most tools can consume both. In this output, I modeled gold.

Wed, Jun 12, 3:09 AM · Restricted Project

Mon, Jun 10

peter.smith committed rG386f3a27db87: [COFF][X86] Add REQUIRES: x86 to a couple of tests (authored by peter.smith).
[COFF][X86] Add REQUIRES: x86 to a couple of tests
Mon, Jun 10, 3:07 AM
peter.smith created D63071: [LLD][COFF] Add REQUIRES: x86 to a couple of tests.
Mon, Jun 10, 2:57 AM · Restricted Project

Fri, Jun 7

peter.smith committed rGe208208a3132: [ELF][AArch64] Support for BTI and PAC (authored by peter.smith).
[ELF][AArch64] Support for BTI and PAC
Fri, Jun 7, 5:58 AM
peter.smith added inline comments to D62609: [LLD][ELF][AArch64] Support for BTI and PAC.
Fri, Jun 7, 5:49 AM · Restricted Project

Thu, Jun 6

peter.smith updated the diff for D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Updated diff to split BtiNeeded into BtiHeader and BtiEntry, and removed Pre in favour of incrementing Buf.

Thu, Jun 6, 2:56 AM · Restricted Project
peter.smith added a comment to D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Thanks for the comments I'll upload a new patch shortly.

Thu, Jun 6, 2:56 AM · Restricted Project

Wed, Jun 5

peter.smith committed rGe12334a0f248: [ELF] Allow reading of more than one FEATURE_1_AND in same object. (authored by peter.smith).
[ELF] Allow reading of more than one FEATURE_1_AND in same object.
Wed, Jun 5, 2:31 AM

Tue, Jun 4

peter.smith edited parent revisions for D62609: [LLD][ELF][AArch64] Support for BTI and PAC, added: 2; removed: 1.
Tue, Jun 4, 10:14 AM · Restricted Project
peter.smith removed a child revision for D59780: Support Intel Control-flow Enforcement Technology: D62609: [LLD][ELF][AArch64] Support for BTI and PAC.
Tue, Jun 4, 10:14 AM · Restricted Project
peter.smith added a child revision for D62853: Read .note.gnu.property sections and emit a merged .note.gnu.property section.: D62609: [LLD][ELF][AArch64] Support for BTI and PAC.
Tue, Jun 4, 10:14 AM · Restricted Project
peter.smith added a child revision for D62862: [ELF][LLD] Allow reading of more than one FEATURE_1_AND in same object.: D62609: [LLD][ELF][AArch64] Support for BTI and PAC.
Tue, Jun 4, 10:14 AM · Restricted Project
peter.smith updated the diff for D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Updated patch to rebase against parents D62853 and D62862

Tue, Jun 4, 10:13 AM · Restricted Project
peter.smith added a comment to D62853: Read .note.gnu.property sections and emit a merged .note.gnu.property section..

I've created D62862 which is independent of X86/AArch64.

D62862 is x86-specific right now?

Tue, Jun 4, 9:46 AM · Restricted Project
peter.smith committed rGf15e3d856fdd: [AArch64][ELF] Add support for PLT decoding with BTI instructions present (authored by peter.smith).
[AArch64][ELF] Add support for PLT decoding with BTI instructions present
Tue, Jun 4, 9:33 AM
peter.smith added a parent revision for D62862: [ELF][LLD] Allow reading of more than one FEATURE_1_AND in same object.: D62853: Read .note.gnu.property sections and emit a merged .note.gnu.property section..
Tue, Jun 4, 9:20 AM · Restricted Project
peter.smith added a child revision for D62853: Read .note.gnu.property sections and emit a merged .note.gnu.property section.: D62862: [ELF][LLD] Allow reading of more than one FEATURE_1_AND in same object..
Tue, Jun 4, 9:20 AM · Restricted Project
peter.smith added a comment to D62853: Read .note.gnu.property sections and emit a merged .note.gnu.property section..

Thanks very much for extracting the .note.gnu.property parsing code. There was one modification I'd made in D62609 that permitted multiple GNU_PROPERTY_X86_FEATURE_1_AND properties in the same .note.gnu.property section as this was observed in the ld.bfd testsuite. I'll submit a patch with just these modifications in.

Tue, Jun 4, 9:20 AM · Restricted Project
peter.smith created D62862: [ELF][LLD] Allow reading of more than one FEATURE_1_AND in same object..
Tue, Jun 4, 9:20 AM · Restricted Project
peter.smith accepted D62853: Read .note.gnu.property sections and emit a merged .note.gnu.property section..

Thanks very much for extracting the .note.gnu.property parsing code. There was one modification I'd made in D62609 that permitted multiple GNU_PROPERTY_X86_FEATURE_1_AND properties in the same .note.gnu.property section as this was observed in the ld.bfd testsuite. I'll submit a patch with just these modifications in.

Tue, Jun 4, 9:05 AM · Restricted Project
peter.smith added a comment to D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.

Thanks for the review.

Tue, Jun 4, 8:14 AM · Restricted Project
peter.smith committed rG49d7221f7195: [AArch64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags (authored by peter.smith).
[AArch64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags
Tue, Jun 4, 4:42 AM
peter.smith committed rG580c6d31c00d: [AARCH64][ELF][llvm-readobj] Support for AArch64 .note.gnu.property (authored by peter.smith).
[AARCH64][ELF][llvm-readobj] Support for AArch64 .note.gnu.property
Tue, Jun 4, 4:27 AM
peter.smith updated the diff for D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Updated diff with single unified PLT that optionally adds in the BTI prefix and AUTIA1716 before branch. This is less code overall as we don't have 4 similar PLT writing functions at the expense of being slightly more complicated.

Tue, Jun 4, 3:42 AM · Restricted Project
peter.smith added a comment to D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Peter, do you want me to separate code to read AndFeatures from https://reviews.llvm.org/D59780 and submit?

Tue, Jun 4, 1:57 AM · Restricted Project

Mon, Jun 3

peter.smith updated the diff for D62596: [AARCH64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags.

I've updated printDynamicEntry as suggested. There are an awful lot of MIPS tags! I've kept them with the same value as before, although I'd think that the NO tags would probably best be output as decimal. I'll leave that decision to the MIPS maintainers.

Mon, Jun 3, 10:51 AM · Restricted Project
peter.smith added a comment to D62768: [ELF] Don't create an output section named `/DISCARD/` if it is assigned to the special phdr `NONE`.

Sorry I didn't follow the discussion in D61186 and didn't notice D61251. It seems @grimar and @peter.smith were fine with D61251 (this patch is essentially D61251). @andrewng if you are ok with letting this somewhat contrived example fail, we can probably still mark this as resolved (wontfix).

Mon, Jun 3, 9:27 AM · Restricted Project
peter.smith updated the diff for D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.

Corrected matching of "BTI c" to only match "BTI c".

Mon, Jun 3, 9:20 AM · Restricted Project
peter.smith added inline comments to D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.
Mon, Jun 3, 9:18 AM · Restricted Project
peter.smith updated the diff for D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

New patch to address review comments. Main changes:

  • Updated Driver.cpp to check that --pac-plt and --force-bti are aarch64 only, add test.
  • Correct number of dashes in docs
  • Fix some comments
  • Update tests to use ## for comments, use --no-show-raw-insn.
Mon, Jun 3, 8:45 AM · Restricted Project
peter.smith added a comment to D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Thanks very much for the comments and questions. I'll upload a new patch in a second.

Mon, Jun 3, 8:41 AM · Restricted Project
peter.smith added a comment to D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

I am reading some binutils-gdb/bfd/elfnn-aarch64.c code as a reference. It doesn't use bti c for -pie (ET_DYN). <del>Is it intentional?</del>

It is intentional, because only indirect branch/call targets need BTI. A PIE PLT is not taken address so no BTI is needed.

Mon, Jun 3, 6:31 AM · Restricted Project
peter.smith updated the diff for D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.

Incorporated George's test case suggestions (Thank You!)

Mon, Jun 3, 5:52 AM · Restricted Project
peter.smith added inline comments to D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.
Mon, Jun 3, 4:15 AM · Restricted Project

Fri, May 31

peter.smith added a comment to D62555: [TailDuplicator] prevent tail duplication for INLINEASM_BR.

so probably a bug in if conversion. Maybe the same issue as https://bugs.llvm.org/show_bug.cgi?id=41121 .

Interesting, and does look related. While I try to make If Converter more robust in the face of INLINEASM_BR, I still think curtailing Tail Duplicator from duplicating INLINEASM_BR (and INLINEASM) is probably also worthwhile, and kind of makes robustness changes to If Converter less important. I'm going to spend the rest of the day trying to improve If Converter, but ultimately this is holding up asm goto from working perfectly (which is more important to me), so if I don't have anything working by EOD, then tomorrow I will make the suggested edits here and focus on this patch.

Fri, May 31, 5:30 AM · Restricted Project
peter.smith added a comment to D62596: [AARCH64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags.

Thanks for the suggestion, I'll update the patch on Monday.

Fri, May 31, 3:50 AM · Restricted Project
peter.smith added a comment to D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.

Thanks for the suggestion, I'll update on Monday.

Fri, May 31, 3:46 AM · Restricted Project

Thu, May 30

peter.smith updated the diff for D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Updated tests to align instructions and use readelf -x .got.plt.

Thu, May 30, 10:00 AM · Restricted Project
peter.smith added a comment to D62609: [LLD][ELF][AArch64] Support for BTI and PAC.

Thanks for the comments, I'll upload another diff with fixes.

Thu, May 30, 9:58 AM · Restricted Project
peter.smith added a comment to D62595: [AARCH64][ELF][llvm-readobj] Support for AArch64 .note.gnu.property.

Thanks for the reviews, I'll move the test to the AArch64 dir and lose the top line. Will do that on Monday as I'll be out of office tomorrow.

Thu, May 30, 9:31 AM · Restricted Project
peter.smith updated the diff for D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.

Updated test to use yaml2obj. Couldn't get obj2yaml to work out of the box, but after heavily cutting down then both yaml2obj and llvm-objdump will accept it.

Thu, May 30, 9:30 AM · Restricted Project
peter.smith updated the diff for D62596: [AARCH64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags.

Updated diff to use yaml2obj. It turns out there was already a processor specific dynamic tags test so I've added to that instead of writing a new one. I've taken the opportunity to separate out the printing of values for [DT_LOPROC, DT_AUXILIARY) so that the types don't clash.

Thu, May 30, 7:34 AM · Restricted Project
peter.smith updated the diff for D62595: [AARCH64][ELF][llvm-readobj] Support for AArch64 .note.gnu.property.

Updated diff to share more of the code with the GNU_PROPERTY_GNU_X86_FEATURE_1_AND. The processor specific feature bits will overlap so these need to be protected. I think this is better than the previous version as we are sharing the parsing code.

Thu, May 30, 3:02 AM · Restricted Project
peter.smith added a comment to D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.

Thanks for the comments, will have an update later today.

Thu, May 30, 2:38 AM · Restricted Project
peter.smith added a comment to D62596: [AARCH64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags.

Thanks for the comments, I hope to have an update later today.

Thu, May 30, 2:33 AM · Restricted Project
peter.smith added inline comments to D62596: [AARCH64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags.
Thu, May 30, 2:31 AM · Restricted Project

Wed, May 29

peter.smith added parent revisions for D62609: [LLD][ELF][AArch64] Support for BTI and PAC: D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present, D62596: [AARCH64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags, D62595: [AARCH64][ELF][llvm-readobj] Support for AArch64 .note.gnu.property, D59780: Support Intel Control-flow Enforcement Technology.
Wed, May 29, 9:51 AM · Restricted Project
peter.smith added a child revision for D62595: [AARCH64][ELF][llvm-readobj] Support for AArch64 .note.gnu.property: D62609: [LLD][ELF][AArch64] Support for BTI and PAC.
Wed, May 29, 9:51 AM · Restricted Project
peter.smith added a child revision for D59780: Support Intel Control-flow Enforcement Technology: D62609: [LLD][ELF][AArch64] Support for BTI and PAC.
Wed, May 29, 9:51 AM · Restricted Project
peter.smith created D62609: [LLD][ELF][AArch64] Support for BTI and PAC.
Wed, May 29, 9:49 AM · Restricted Project
peter.smith created D62598: [AArch64][ELF][llvm-objdump] Add support for PLT decoding with BTI instructions present.
Wed, May 29, 8:16 AM · Restricted Project
peter.smith created D62596: [AARCH64][ELF][llvm-readobj] Add support for BTI and PAC dynamic tags.
Wed, May 29, 8:06 AM · Restricted Project
peter.smith created D62595: [AARCH64][ELF][llvm-readobj] Support for AArch64 .note.gnu.property.
Wed, May 29, 8:02 AM · Restricted Project
peter.smith added a comment to D62555: [TailDuplicator] prevent tail duplication for INLINEASM_BR.

I can see how this change would prevent the TailDuplication pass from duplicating blocks with callbr instructions, however I'm not sure if that is sufficient, or if it is too restrictive.

  • Is it possible to write C code that results in IR as if the TailDuplication pass has duplicated the callbr, or is there a fundamental part of asm goto that prevents this from happening?
  • Do we know of other passes that might fail due to TailDuplication of callbr?
  • Could this be fixed in the if conversion pass IfConverter::ScanInstructions() by having TargetInstrInfo::isPredicable(MachineInstr&) reject TargetOpcode::INLINEASM_BR?
Wed, May 29, 3:16 AM · Restricted Project

Tue, May 28

peter.smith added a comment to D59780: Support Intel Control-flow Enforcement Technology.

Ping. I'm planning to upstream support for the AArch64 BTI and PAC features in LLD, llvm-objdump and llvm-readelf. I've written the LLD patches on top of this patch as the .note.gnu.property section is used in a similar way (GNU_PROPERTY_AARCH64_FEATURE_1_AND) so only a few small alterations are needed to that part of the code. I'm wondering if it is best to:

  • Submit the patches rebased on top of this patch.
    • The advantage here is that you could see the differences in supporting X86 and AArch64 more clearly.
  • Strip out the .note.gnu.property code from this patch and resubmit it as part of the AArch64 BTI and PAC.
    • The advantage here is that the AArch64 feature doesn't have to wait for CET to land.
Tue, May 28, 10:32 AM · Restricted Project
peter.smith accepted D62365: ELF: Don't reuse a thunk in a different loadable partition..

Thanks for the update. I've marked as accepted as I think only mechanical changes will be needed if D60353 changes Partition representation.

Tue, May 28, 2:31 AM · Restricted Project

Fri, May 24

peter.smith accepted D62402: [AArch64] check for INLINEASM_BR along w/ INLINEASM.

LGTM. Unlike with the ARM constant pools, I've no idea how to write a test case to trigger an error here.

Fri, May 24, 9:30 AM · Restricted Project
peter.smith accepted D62400: [ARM] additionally check for ARM::INLINEASM_BR w/ ARM::INLINEASM.

Code change looks good to me. All the places that ARM::INLINE_ASM are mentioned now take into account ARM::INLINEASM_BR.

Fri, May 24, 9:29 AM · Restricted Project
peter.smith added a comment to D62365: ELF: Don't reuse a thunk in a different loadable partition..

Raised PR42006 for the OVERLAY behaviour https://bugs.llvm.org/show_bug.cgi?id=42006

Fri, May 24, 7:00 AM · Restricted Project
peter.smith added a comment to D62365: ELF: Don't reuse a thunk in a different loadable partition..

I think this is the right thing to do. I've left a suggestion to abstract the names a bit as I think that there are some other cases where we don't want to reuse Thunks across OutputSection boundaries.

Fri, May 24, 2:17 AM · Restricted Project

Tue, May 21

peter.smith added a comment to D62177: [ELF] Don't advance position in a memory region when assigning to the Dot.

Thanks for the fix. The MEMORY command is indeed strange. I think that this behaviour is documented in https://sourceware.org/binutils/docs/ld/Output-Section-Address.html#Output-Section-Address

The output section address heuristic is as follows:
Tue, May 21, 3:03 AM · Restricted Project

Mon, May 20

peter.smith added inline comments to rL183729: ARM: Fix STREX/LDREX reecoding.
Mon, May 20, 2:56 AM

May 17 2019

peter.smith added a comment to D62055: [ARM][AArch64] Revert Android Bionic PT_TLS overaligning hack.

I'm happy to go along with the Android folks decision here.

May 17 2019, 1:53 AM · Restricted Project
peter.smith added a comment to D62051: [ELF][test] Reorganize some R_*_NONE tests.

I've no objections to making this change.

May 17 2019, 1:48 AM · Restricted Project
peter.smith accepted D62052: [ELF] -r: fix R_*_NONE to section symbols on Elf*_Rel targets.

LGTM. The addend in a R_*_NONE relocation is not meaningful anyway as the relocation is never resolved to a value.

May 17 2019, 1:46 AM · Restricted Project

May 16 2019

peter.smith accepted D61973: [AArch64] Support .reloc *, R_AARCH64_NONE, *.

Thanks, looks good to me. Will be worth seeing if there are any further comments from the US Timezone.

May 16 2019, 8:10 AM · Restricted Project
peter.smith accepted D61992: [ARM] Support .reloc *, R_ARM_NONE, *.

Thanks, this looks good to me. May be worth waiting before committing to see if there are any comments from the US timezone.

May 16 2019, 6:49 AM · Restricted Project
peter.smith added a comment to D61973: [AArch64] Support .reloc *, R_AARCH64_NONE, *.

To get back to this patch. I think the non-bigendian comments I made on D61992 apply here as well. Generally looks good. Will be worth checking that the format is ELF before accepting R_AARCH64_NONE.

May 16 2019, 6:49 AM · Restricted Project
peter.smith added a comment to D61973: [AArch64] Support .reloc *, R_AARCH64_NONE, *.

I think the ld -r failure with arm is due to InputSection::copyRelocations(uint8_t *Buf, ArrayRef<RelTy> Rels) in particular:

May 16 2019, 6:41 AM · Restricted Project
peter.smith added a comment to D61973: [AArch64] Support .reloc *, R_AARCH64_NONE, *.

I have similar comments to D61992

May 16 2019, 6:15 AM · Restricted Project
peter.smith added a comment to D61992: [ARM] Support .reloc *, R_ARM_NONE, *.

I think this is looking close. I've got a small concern about what happens on non-ELF platforms Windows and Macho where R_ARM_NONE is not defined. Other than that it is just a few suggestions.

May 16 2019, 4:29 AM · Restricted Project
peter.smith added a comment to D61992: [ARM] Support .reloc *, R_ARM_NONE, *.

I get an assertion failure from this patch on the armv7eb-linux-gnueabi test case: llvm/lib/Target/ARM/MCTargetDesc/ARMAsmBackend.cpp:872! (the llvm_unreachable)

May 16 2019, 3:13 AM · Restricted Project

May 15 2019

peter.smith added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.

I'm not sure I understand the comment about ALIGNUP, did you mean the linker script command ALIGN? I guess by perceivable you mean it has more impact on the file and following sections?

Sorry, I meant ALIGNOF. If we lower the hack to the OutputSection layer, it may interfere with linker scripts. Though my understanding about linker scripts is largely learned from lld source, I don't use linker scripts myself so I am not very clear what issues it may cause.

I think that should be fine. If someone happened to write ALIGNOF(.tbss) then it would return the higher value, which would be consistent with the actual section alignment. The only reason I can think of for doing that is to roll their own TLS implementation using linker defined symbols rather than the PT_TLS segment.

May 15 2019, 9:20 AM · Restricted Project
peter.smith added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.

I have a question based on the updated description of D61825 (makes more sense in the context of this patch)

- Moving the hack to the OutputSection layer makes the hack more perceivable as it has interaction with the linker script ALIGNUP command.
- It may waste up to 8*WordSize * 2 bytes of each thread (when both .tbss and .tdata exist and are overaligned). With more code, we can apply the overalignment to the first TLS output section (either .tbss or .tdata) and decrease the wastage to 8*WordSize, but that is still unsatisfactory on other platforms.

I'm not sure I understand the comment about ALIGNUP, did you mean the linker script command ALIGN? I guess by perceivable you mean it has more impact on the file and following sections?

May 15 2019, 6:51 AM · Restricted Project
peter.smith added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.

Aside: An R_{ARM,AARCH64}_NONE relocation to a TLS symbol has the desired effect. Is there a better way to create this relocation than by using a hex editor?

why not export the symbol?
then it cannot be removed for sure.
(i think gas has a .reloc directive that accepts R_AARCH64_NONE as argument, not sure if llvm handles that)

May 15 2019, 6:12 AM · Restricted Project

May 13 2019

peter.smith committed rG4e21c770ec32: [ELF] Full support for -n (--nmagic) and -N (--omagic) via common page (authored by peter.smith).
[ELF] Full support for -n (--nmagic) and -N (--omagic) via common page
May 13 2019, 9:02 AM
peter.smith added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.

Below is my understanding about how glibc is wrong. glibc/elf/dl-tls.c:250 (the #elif TLS_DTV_AT_TP part)

// I don't know what this piece of code intended to do with non-zero firstbyte...
off = roundup (offset, slotinfo[cnt].map->l_tls_align); // roundup(16, 64) = 64
if (off - offset < firstbyte) // 64 - 16 ; 32
  off += slotinfo[cnt].map->l_tls_align;
slotinfo[cnt].map->l_tls_offset = off - firstbyte; // 64 - 32 = 32, wrong, should be 64

// If firstbyte is 0 (i.e. p_vaddr % l_tls_align == 0), this is simply:
off = roundup (offset, slotinfo[cnt].map->l_tls_align);
slotinfo[cnt].map->l_tls_offset = off;
// and is correct
May 13 2019, 8:16 AM · Restricted Project
peter.smith added a comment to D61688: [LLD][ELF] Full support for -n (--nmagic) and -N (--omagic) via -zcommon-page-size.

Thanks for the reviews, I'll fix the nits, and will add a comment to describe the difference between max and common page size.

May 13 2019, 6:18 AM · Restricted Project
peter.smith added a comment to D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0.

I think that this will definitely fix the problem, but I'd like to understand a bit more about what glibc is doing and what assumptions it is making, there does seem to be some code that attempts to deal with a PT_TLS with p_vaddr != 0 modulo p_align. My understanding from looking at dt-tls.c _dl_determine_tlsoffset() which sets the offset of each tls block (with the executable being in slot 0). Does something like this:

  • offset = TLS_TCB_SIZE (hard-coded to 2 * (void*) pointers.
  • calculates firstbyte, which is derived from l_tls_firstbyte_offset which is PT_TLS p_vaddr % p_align. For the example in pr41527 this is 32 bytes
  • sets the l_tls_offset of slot 0 to alignto(offset, p_align) - firstbyte.
May 13 2019, 4:18 AM · Restricted Project

May 9 2019

peter.smith updated the diff for D61688: [LLD][ELF] Full support for -n (--nmagic) and -N (--omagic) via -zcommon-page-size.

Update diff to add (default) to the --no-omagic and --no-nmagic options.

May 9 2019, 8:11 AM · Restricted Project
peter.smith added a comment to D61688: [LLD][ELF] Full support for -n (--nmagic) and -N (--omagic) via -zcommon-page-size.

Sorry for my ignorance, but I don't think I fully understand the difference of "page size" and "common page size". In what situation you want to set different values to these variables? Is there any constraint between them, such as one value is always greater than the other, etc.?

May 9 2019, 5:42 AM · Restricted Project
peter.smith abandoned D61201: [LLD][ELF] Full support for -n (--nmagic) and -N (--omagic).

Abandoned in favour of a different approach D61688

May 9 2019, 3:58 AM

May 8 2019

peter.smith added a comment to D61201: [LLD][ELF] Full support for -n (--nmagic) and -N (--omagic).

https://sourceware.org/bugzilla/show_bug.cgi?id=24505 doesn't get a response, but I researched the users of CONSTANT(...):

CONSTANT(COMMONPAGESIZE): 2 users: edk2, u-boot
CONSTANT(MAXPAGESIZE): 1 user: fuchsia zircon, but they don't use -n or -N

u-boot and fuchsia zircon don't seem to use -n or -N. edk2 is probably the only project that uses both -n/-N and CONSTANT(...). It has DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -Wl,-n,-q,--gc-sections -z common-page-size=0x20

We probably shouldn't be constrained by ld.bfd's behavior for this single user,
if making MaxPageSize and PageSize to 1 makes our implementation simpler.

The potential users can make straightforward changes to adapt to lld's behavior: change CONSTANT(COMMONPAGESIZE) to a literal constant.

I'll make an alternative implementation that in effect implements -z common-page, and have -n/-N set it to 1 and will post as a separate review. It will probably be of similar complexity to this. In the example above it does look to be using -z common-page-size and CONSTANT(COMMONPAGESIZE) as a way of passing a parameter to the linker script.

May 8 2019, 8:52 AM
peter.smith created D61688: [LLD][ELF] Full support for -n (--nmagic) and -N (--omagic) via -zcommon-page-size.
May 8 2019, 8:51 AM · Restricted Project
peter.smith added a comment to D61666: [ELF] Optimize getISDThunkSec() to amortized O(1) in thunk creation.

If I understand correctly I think this could prematurely skip over ThunkSections if there is more than one branch relocation range. For example consider a case where there are two relocation ranges S (short) and L (long). If we search for a ThunkSection for S where the ThunkSection spacing is L then there is a chance that at a relocation with range S at offset O will be out of range of one of more ThunkSections, but these would have been in range had it been R. The next relocation with range L at offset O2 will not even check some ThunkSections that it would have been in range of. The chances of this happening are much greater when S is much smaller than L.

May 8 2019, 2:48 AM · Restricted Project
peter.smith added a comment to D61610: [PPC64] implement Thunk Section Spacing.

I was trying to find a good value used in
uint32_t PPC64::getThunkSectionSpacing() const { return 0x8000 - 0x1000; } before I noticed this caused an extreme slowdown in thunk creation.

We have a large program whose text segment is of 1.3GiB. Its OutputSection .text consists of 1948775 InputSections. It takes 20 seconds to link but with this patch it doesn't stop in 10 minutes.

The reason is that:

// O(|ThunkVec|). Not the critical path, but there is a bottleneck, too. Many ThunkVec's have hundreds/thousands of elements
            std::tie(T, IsNew) = getThunk(*Rel.Sym, Rel.Type, Src); 

            if (IsNew) { // called 112353 times
              // Find or create a ThunkSection for the new Thunk
              ThunkSection *TS;
              if (auto *TIS = T->getTargetInputSection())
                TS = getISThunkSec(TIS);
              else
                TS = getISDThunkSec(OS, IS, ISD, Rel.Type, Src); // it takes O(|ISD->ThunkSections|) time, `ISD->ThunkSections` is large (25980) when getThunkSectionSpacing is enabled.
              TS->addThunk(T);
              Thunks[T->getThunkTargetSym()] = T;
            }
May 8 2019, 1:59 AM · Restricted Project