Page MenuHomePhabricator
Feed Advanced Search

Fri, Aug 16

peter.smith updated the diff for D66346: [LLD][ELF][ARM] Add a test that maxes out the thunk convergence limit.

Thanks for the comments. I've merged the .text sections and have made an attempt at improving the comments.

Fri, Aug 16, 11:08 AM · Restricted Project
peter.smith added a comment to D66279: [ELF] Make LinkerScript::assignAddresses iterative.

I've created D66346 which maxes out the permitted Thunk convergence limit. I've done it as Arm rather than AArch64 as the range limits are lower on Arm. This should be sufficient to test that if there is any interaction between convergence limits. Apologies for the delay in putting it together.

Fri, Aug 16, 7:07 AM · Restricted Project
peter.smith created D66346: [LLD][ELF][ARM] Add a test that maxes out the thunk convergence limit.
Fri, Aug 16, 6:44 AM · Restricted Project
peter.smith added a comment to D66337: [AArch64InstrInfo] Stop getInstSizeInBytes returning non-zero for meta instructions..

Have I got the terminology the wrong way round? I assumed relaxing meant the act of converting a branch who destination is not within range into a one that is within range either by inversion or introducing a second branch with sufficient range. I just want to make sure my commit message makes sense.

Fri, Aug 16, 5:22 AM · Restricted Project
peter.smith accepted D66337: [AArch64InstrInfo] Stop getInstSizeInBytes returning non-zero for meta instructions..

Looks good to me.

Fri, Aug 16, 3:54 AM · Restricted Project

Thu, Aug 15

peter.smith added a comment to D66279: [ELF] Make LinkerScript::assignAddresses iterative.

I think that this is close. I've got some concerns about the interaction of convergence limits, and it may be worth investigating if it is possible to make a separate symbol update pass that runs after addresses have stabilized.

Thu, Aug 15, 3:12 AM · Restricted Project
peter.smith added a comment to D66277: [ELF][AArch64] Improve error message for unknown relocations.

Looks good to me. George's suggestion for a test is a good one. From a brief look some of the other targets also return R_ABS by default from getRelExpr, such as ARM, PPC, PPC64, Hexagon, MSP430, AVR. I don't think it is worth applying this method universally to all of them, but it may be worth ARM, PPC and PPC64. When this goes in I'd be happy to submit a similar patch for ARM.

Thu, Aug 15, 2:10 AM · Restricted Project

Tue, Aug 13

peter.smith added a comment to D66130: [ELF] Initialize 2 fields of Symbol in SymbolTable::insert.

LGTM too, I agree with George that making the comment specific isn't helpful but a general one isn't doing any harm.

Tue, Aug 13, 2:59 AM · Restricted Project
peter.smith accepted D65995: [ELF] Don't special case symbolic relocations with 0 addend to ifunc in writable locations.

Given that this is mostly deleting code, I'm happy to approve.

Tue, Aug 13, 1:47 AM · Restricted Project
peter.smith added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

I'm personally in favour of accepting D64930 and D64906 (I think that there is also D65865 on X86) as I think that this is an important size optimization already performed by Gold and BFD. Thinking about how to progress this further, I think it would be good to write a summary of where each of these reviews is at and what the plan is for this feature. For example:

  • Have all the comments been addressed, I think the main concern was about TLS?
  • Which targets do we want this to apply to, all of them, or just those with a 64k page size?
  • What is the dependency tree of the reviews, I think D64906 is a pre-requisite for all of them?
  • Does anyone have any objection, or are they happy for individual people active in a backend to approve that part?
Tue, Aug 13, 1:45 AM · Restricted Project
peter.smith accepted D66091: [ELF] Simplify handling of exportDynamic and isPreemptible.

Thanks for the update, this looks a lot easier to understand. Looks good to me.

Tue, Aug 13, 1:20 AM · Restricted Project
peter.smith added a comment to D65995: [ELF] Don't special case symbolic relocations with 0 addend to ifunc in writable locations.
In D65995#1626365, @pcc wrote:

HWASAN should only be using GOT relative relocations to access shadow memory, so I wouldn't expect this change to have an impact on HWASAN.

Thanks for clarification!

Thanks, I've no more objections.

Tue, Aug 13, 12:44 AM · Restricted Project

Mon, Aug 12

peter.smith added a comment to D66091: [ELF] Simplify handling of exportDynamic and isPreemptible.

The code changes look good to me. I've made some suggestions on the name of the flag and some of the comments.

Mon, Aug 12, 11:18 AM · Restricted Project
peter.smith added a comment to D65995: [ELF] Don't special case symbolic relocations with 0 addend to ifunc in writable locations.

If I've understood correctly, this will make the case "address of an ifunc is taken from RW but there are no other relocations that would create a canonical PLT entry" worse as we would always create the canonical PLT entry even if it isn't strictly needed. The trade off is simpler code and a possible size saving from only needing one irelative relocation?

We have probably overloaded the meaning of "canonical PLT" here:) Let me give a bit more details about the two types of canonical PLT:

  1. STT_FUNC, Undefined or SharedSymbol. The canonical PLT makes it a Defined and exports it (replaceWithDefined sets the exportDynamic field) in the dynamic symbol table. This fake definition (st_value=addr(PLT)!=0, st_shndx=0, ld.so has logic to handle such symbols) can preempt a real definition in a DSO. This can be seen as an address leak (in AArch64 BTI protection such PLT needs BTI c).
  2. STT_IFUNC, Defined. The canonical PLT is created because the symbol is referenced by a non-PLT-generating-non-GOT-generating relocation. This case is already a Defined, so there is no new Defined (exportDynamic field is not set). We just change some fields of the symbol (st_value and st_type are important to ld.so. For st_shndx, as long as is non-zero, it doesn't matter what its actual value is). If the STT_GNU_IFUNC symbol was exported before, the converted STT_FUNC is still exported. If the STT_GNU_IFUNC was not (e.g. local/hidden), the new STT_FUNC is not.

    Both are created for pointer equality. This patch deals with 2).

    If the ifunc is referenced by another component.
  3. Without a canonical PLT, its type is STT_GNU_IFUNC. A reference (symbolic relocation/GLOB_DAT/JUMP_SLOT) has to call the ifunc resolver to get the real address.
  4. With a canonical PLT, its type is STT_FUNC. A reference does not have to call the ifunc resolver, but every subsequent function call has to go through the canonical PLT. Address taken of a non-preemptable ifunc in a static storage (.rodata, .data, etc) is rare, so when making the trade-off, we can lean toward implementation complexity.
Mon, Aug 12, 7:06 AM · Restricted Project
peter.smith added a comment to D66007: [ELF] Move (copy relocation/canonical PLT) before error checking.

Thanks for the update, I've no more comments.

Mon, Aug 12, 2:48 AM · Restricted Project

Fri, Aug 9

peter.smith added a comment to D66007: [ELF] Move (copy relocation/canonical PLT) before error checking.

Not got a strong opinion here, happy to go with the consensus.

Fri, Aug 9, 9:54 AM · Restricted Project
peter.smith added a comment to D65995: [ELF] Don't special case symbolic relocations with 0 addend to ifunc in writable locations.

If I've understood correctly, this will make the case "address of an ifunc is taken from RW but there are no other relocations that would create a canonical PLT entry" worse as we would always create the canonical PLT entry even if it isn't strictly needed. The trade off is simpler code and a possible size saving from only needing one irelative relocation?

Fri, Aug 9, 8:40 AM · Restricted Project

Thu, Aug 8

peter.smith added a comment to D65857: [MC][AArch64] Restrict use of signed relocation operators on MOV[NZK].

Thanks for getting back to me, I'll look into making a strict mode. I'll also mention the use case you've identified with movk to my colleague from our GCC team, it is a pity that we don't have a R_AARCH64_PREL_G3_NC for the movk as although not ideal, as it is skipping an overflow check, it would permit GNU ld to be extended whilst retaining the property that you don't need to disassemble the binary to know how to evaluate a relocation.

Thu, Aug 8, 10:03 AM
peter.smith committed rGd4695e1d75a3: [ELF][AArch64] Support for movz, movk tprel relocations (authored by peter.smith).
[ELF][AArch64] Support for movz, movk tprel relocations
Thu, Aug 8, 6:39 AM
peter.smith added a comment to D65882: [LLD][ELF][AArch64] Support for movz, movk tprel relocations.

Thanks for the review, I've applied the changes to the test prior to commit.

Thu, Aug 8, 6:38 AM · Restricted Project
peter.smith added a comment to D65857: [MC][AArch64] Restrict use of signed relocation operators on MOV[NZK].
In D65857#1619366, @pcc wrote:

MHO: The assembler is a low enough level component that the user can be presumed to know what they're doing, regardless of linker limitations. So I would prefer not to do this. If we do anything about this, we should document the limitations of the GNU linkers somewhere.

Thu, Aug 8, 6:18 AM

Wed, Aug 7

peter.smith created D65882: [LLD][ELF][AArch64] Support for movz, movk tprel relocations.
Wed, Aug 7, 8:17 AM · Restricted Project
peter.smith added a comment to D65857: [MC][AArch64] Restrict use of signed relocation operators on MOV[NZK].

I will also need to fix up the LLD test/ELF/aarch64-reloc.s as this is the only place where the signed relocations are used with _nc on mov[nz] and the checked on movk. A simple change that works is:

 .section .R_AARCH64_MOVW_PREL,"ax",@progbits
    movz x1, #:prel_g0:.+1
-   movz x1, #:prel_g0_nc:.-1
-   movk x1, #:prel_g0:.+1
+   movn x1, #:prel_g0:.-1
+   movk x1, #:prel_g0_nc:.+1
    movk x1, #:prel_g0_nc:.-1
    movz x2, #:prel_g1:.+0x20000
-   movz x2, #:prel_g1_nc:.-0x20000
-   movk x2, #:prel_g1:.+0x20000
+   movn x2, #:prel_g1:.-0x20000
+   movk x2, #:prel_g1_nc:.+0x20000
    movk x2, #:prel_g1_nc:.-0x20000
    movz x3, #:prel_g2:.+0x300000000
-   movz x3, #:prel_g2_nc:.-0x300000000
-   movk x3, #:prel_g2:.+0x300000000
+   movn x3, #:prel_g2:.-0x300000000
+   movk x3, #:prel_g2_nc:.+0x300000000
    movk x3, #:prel_g2_nc:.-0x300000000
    movz x3, #:prel_g2:.+0x300000000
    movz x4, #:prel_g3:.+0x4000000000000
    movz x4, #:prel_g3:.-0x4000000000000
-   movk x4, #:prel_g3:.+0x4000000000000
-   movk x4, #:prel_g3:.-0x4000000000000
Wed, Aug 7, 6:41 AM
peter.smith created D65857: [MC][AArch64] Restrict use of signed relocation operators on MOV[NZK].
Wed, Aug 7, 3:54 AM

Tue, Aug 6

peter.smith committed rG7f320d4bf074: [ELF][ARM] Fix /DISCARD/ of section with .ARM.exidx section (authored by peter.smith).
[ELF][ARM] Fix /DISCARD/ of section with .ARM.exidx section
Tue, Aug 6, 7:18 AM
peter.smith updated the diff for D65759: [ELF][ARM] Fix /DISCARD/ of section with .ARM.exidx section.

Thanks very much for the comments. I've updated the description, comment, used llvm::erase_if and combined the llvm-readobj into one call.

Tue, Aug 6, 3:40 AM · Restricted Project
peter.smith accepted D65550: [AArch64] Do not emit '#' before immediates in inline asm.

I've built a defconfig aarch64 linux kernel without errors including this change.

Tue, Aug 6, 2:15 AM · Restricted Project

Mon, Aug 5

peter.smith created D65759: [ELF][ARM] Fix /DISCARD/ of section with .ARM.exidx section.
Mon, Aug 5, 10:54 AM · Restricted Project
peter.smith added a comment to D65716: [ELF] Consistently prioritize non-* wildcards overs "*" in version scripts.

Thanks for the update. I've not got any more comments.

Mon, Aug 5, 5:42 AM · Restricted Project
peter.smith added a comment to D65716: [ELF] Consistently prioritize non-* wildcards overs "*" in version scripts.

Overall looks good to me. I've got a few suggestions on the refactoring. One other thing that might be worth doing to make this easier to review is to split it into two patches:

  • A refactoring change that doesn't change the wildcard behaviour.
  • The change to the wildcard behaviour.

Not got a strong opinion on that now I've gone through it.

Mon, Aug 5, 3:13 AM · Restricted Project

Fri, Aug 2

peter.smith committed rGf5b91f2a0f9d: [AliasAnalysis] Initialize a member variable that may be used by unit test. (authored by peter.smith).
[AliasAnalysis] Initialize a member variable that may be used by unit test.
Fri, Aug 2, 1:11 AM

Thu, Aug 1

peter.smith added a comment to D65584: [ELF] Make binding (weak or non-weak) logic consistent for Undefined and SharedSymbol.

IIUC the desired state you are proposing is:

Thu, Aug 1, 9:34 AM · Restricted Project
peter.smith added a comment to D65550: [AArch64] Do not emit '#' before immediates in inline asm.

A colleague has pointed out to me that there is a way of using the c modifier after the % "Require a constant operand and print the constant expression with no punctuation" that works with both clang and GCC. See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#InputOperands in your example above it would be:

__asm__ ("fmla v2.4s, v0.4s, v1.s[%c0]" :: "I"(0x1))

I still think that it could be useful to have GCC and Clang have the same behaviour for "I", but at least there is a workaround available for this case.

Thu, Aug 1, 4:27 AM · Restricted Project
peter.smith created D65568: [AliasAnalysis] Initialize a member variable that may be used by unit test..
Thu, Aug 1, 3:23 AM · Restricted Project
peter.smith added a comment to D64906: [ELF][PPC] Allow PT_LOAD to have overlapping p_offset ranges.

I'm happy to go ahead as this is a pre-requisite for supporting AArch64.

Thu, Aug 1, 3:23 AM · Restricted Project
peter.smith added reviewers for D65550: [AArch64] Do not emit '#' before immediates in inline asm: nickdesaulniers, t.p.northover, efriedma, ostannard.

I think that this will need a wider review to make check if anyone is dependent on the '#'. My personal opinion is that this is a good change to make as it will make the 'I' constraint more generally useful, without it we may need a new constraint that doesn't add a '#':

  • The # is optional for immediates.
  • GNU assembler and Clang both fault # in an element index, correctly according to my reading of the Arm ARM.
  • GCC does not output the # when expanding the 'I' constraint
    • A colleague mentioned that there may be other cases where a # might be problematic, such as ".byte %0" in a switched section.
Thu, Aug 1, 2:15 AM · Restricted Project

Wed, Jul 31

peter.smith committed rGe314a128a9d6: [AARCH64] Switch relocations R_AARCH64_TLS_TPREL64 and R_AARCH64_DTPMOD64 (authored by peter.smith).
[AARCH64] Switch relocations R_AARCH64_TLS_TPREL64 and R_AARCH64_DTPMOD64
Wed, Jul 31, 7:45 AM
peter.smith closed D65459: [AARCH64] Renumber relocation codes R_AARCH64_TLS_TPREL64 and DTPMOD64.

Thanks for the review, committed r367437. Forgot to put differential revision so it won't automatically get closed, apologies.

Wed, Jul 31, 7:45 AM

Tue, Jul 30

peter.smith created D65459: [AARCH64] Renumber relocation codes R_AARCH64_TLS_TPREL64 and DTPMOD64.
Tue, Jul 30, 9:48 AM
peter.smith added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

I'm not sure about breaking the (p_vaddr % p_align == 0) invariant. ld.bfd, gold, and (for the most part) lld currently provide this invariant for TLS segments in output files.

Supporting n-mod-m alignment isn't free for dynamic TLS -- allocators typically have [posix_]memalign and free APIs, but I'm not aware of APIs that provide n-mod-m alignment. Supporting it may add extra overhead in libc (e.g. in the DTV) to accommodate the misalignment so libc can free the memory later. The n-mod-m property could conceivably leak into an API used for sanitizers (e.g. https://sourceware.org/glibc/wiki/ThreadPropertiesAPI, the proposed __libc_create_dynamic_tls API).

I think there's an interoperability/compatibility issue. Like current Bionic, I don't think the BSDs pay attention to the (p_vaddr % p_align) value, for static or dynamic TLS. glibc uses that value for static TLS segments, but not for dynamic TLS[1]. (i.e. With this change, I believe lld can generate DSOs where some .tbss variables are misaligned when dlopen'ed with glibc.)

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=24606

Tue, Jul 30, 8:06 AM · Restricted Project
peter.smith added a comment to D65430: Add `--dependency-files` option, which is equivalent to compiler option -MD..

No objections to the idea in principle. I think it may need a bit of wider discussion to reach its full potential though. My understanding is that many developers use makefile/ninja generation systems such as cmake rather than hand-write the file themselves. As such would this get much use unless it was integrated into these generators? May be worth approaching them to see if they have any requirements/observations about the option?

Tue, Jul 30, 4:11 AM · Restricted Project

Mon, Jul 29

peter.smith added a comment to D65222: [IPSCCP] Add assertion to surface cases where we zap returns with overdefined users..

I do have a mail from our CI system with a series of reproducible steps that can clone and checkout revisions of LLVM and Linux that can cross-compile the linux kernel for aarch64 on an x86_64 linux machine that I'll forward on to you. I also have the preprocessed source of kernel/signal.c that failed that I'll include in the mail but I can also probably add to a PR if I compress it.

Would you be able to take a look to see if the failures are genuine bugs in clang that the assertion has uncovered or whether it is triggering by mistake?

Would it be possible to provide the bitcode file before LTO without too much effort? The reproducer builds fine on macOS without -fuse-ld=lld (fuse-ld=lld fails with an unrelated error) but unfortunately I do not have access to a suitable Linux system for cross-compiling to armv7a-linux-gnueabihf

Mon, Jul 29, 7:36 AM · Restricted Project

Fri, Jul 26

peter.smith added a comment to D65222: [IPSCCP] Add assertion to surface cases where we zap returns with overdefined users..

A couple of our CI jobs have found this assertion triggering. The first is when compiling the linux kernel using allmodconfig. The second is on this reduced example using LTO:

Thanks, that's interesting, I'll take a look. This is also triggering a different assertion in this job: https://ci.linaro.org/job/tcwg_kernel-build-llvm-master-aarch64-mainline-allmodconfig/401/ (@nickdesaulniers made me aware) and I think I should have a reproducer for that issue as well shortly. I should know what's going on on Monday the latest. If it is blocking your jobs, should we revert it in the meantime?

Fri, Jul 26, 8:53 AM · Restricted Project
peter.smith added a comment to D65222: [IPSCCP] Add assertion to surface cases where we zap returns with overdefined users..

A couple of our CI jobs have found this assertion triggering. The first is when compiling the linux kernel using allmodconfig. The second is on this reduced example using LTO:

Fri, Jul 26, 8:10 AM · Restricted Project

Thu, Jul 25

peter.smith accepted D65000: [ARM] Set default alignment to 64bits.

I've not seen any objections so I've approved LGTM.

Thu, Jul 25, 8:22 AM · Restricted Project, Restricted Project

Wed, Jul 24

peter.smith added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

My use of TCB comes from the Arm ABI description of TLS http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045e/IHI0045E_ABI_addenda.pdf (See diagram in 3.3 Linux for ARM TLS addressing). I'm guessing that TCB was derived from the original Drepper documentation. If it isn't universal across all TLS implementations we might be better off with something like "Reserved". For me as someone not familiar with MUSL I interpret GAP_ABOVE_TP as the gap between TP and the first TLS block (including the alignment padding and not distinct from it).

Wed, Jul 24, 3:00 AM · Restricted Project
peter.smith added a comment to D64903: [ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with traps only if -z separate-code is specified.

Ping :)

Wed, Jul 24, 2:48 AM · Restricted Project

Tue, Jul 23

peter.smith added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

Will be worth mentioning that this is dependent on D64906 and D64903, I could guess at D64903 but basic-aarch64.s didn't apply cleanly without D64903. I successfully did a 2 stage bootstrap of clang with ninja check-all on a native aarch64 machine and made a quick test to check the TP relative relocation. I struggled a bit to understand the description and the comments though. In particular the use of GAP_ABOVE_TP instead of TCB_SIZE, it also wasn't clear where the alignment calculation had come from. I've made a few suggestions.

Tue, Jul 23, 8:58 AM · Restricted Project

Mon, Jul 22

peter.smith added a comment to D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges.

Apologies, missed that this was a separate review from D64906 will check through in detail tomorrow.

Mon, Jul 22, 10:28 AM · Restricted Project
peter.smith added a comment to D65000: [ARM] Set default alignment to 64bits.

test case missing A8 aside this looks ok to me. Would like to see if there are any comments from the Pacific time zone.

Mon, Jul 22, 9:32 AM · Restricted Project, Restricted Project
peter.smith added a comment to D65000: [ARM] Set default alignment to 64bits.

Thanks for the update. Will be worth adding some reviewers from Apple to see if this change should be IsAAPCS only. I've no more further comments myself besides a small nit on style.

Mon, Jul 22, 3:26 AM · Restricted Project, Restricted Project
peter.smith added reviewers for D65000: [ARM] Set default alignment to 64bits: srhines, danalbert.

I think that this may not apply for Android as AFAIK their ABI still requires 128-bit alignment in some cases. Adding some more reviewers from Android.

Mon, Jul 22, 2:08 AM · Restricted Project, Restricted Project

Jul 19 2019

peter.smith added a comment to D64903: [ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with traps only if -z separate-code is specified.

Although I don't think that it applies to this current patch as I believe that only part of -z separate-code is implemented here. A colleague of mine mentioned that if we have a linker script similar to GNU ld's default, where the .text section is before .rodata then we need to be careful not to include the ELF headers in the executable segment. This won't be an issue for LLD's default image layout as the ro-data comes before the .text.

Jul 19 2019, 3:56 AM · Restricted Project
peter.smith added a comment to D64906: [ELF][PPC] Allow PT_LOAD to have overlapping p_offset ranges.

I would like to do a bit more research about RELRO, as I can't see from this patch alone. I think it is fine if RELRO is double mapped into an RO page. However if RELRO is adjacent to RW segments I think it could be a bad idea to have something like

VA [0x10000, 0x10020).data.rel.roPA [0x10000, 0x10020)
VA [0x20020, ...).dataPA [0x10020, ...)

As in theory (I'm not sure about how this works in the OS/loader so I could have this wrong) if the physical contents of .data was mapped RW from 0x10000 -> 0x20000 we'd have an ability to write to the .data.rel.ro via .data.

Is there some other part of the code that prevents this or does some other mechanism in the loader/OS prevent this from happening?

Jul 19 2019, 3:40 AM · Restricted Project
peter.smith added a comment to D64906: [ELF][PPC] Allow PT_LOAD to have overlapping p_offset ranges.

As I understand it this will only affect the non-linker script case as fixSectionAlignments() will only be called when there is no script->hasSectionsCommand. It will be worth making this clear in the description. I expect to get equivalent behaviour in the linker script we'd need to alter the implementation of DATA_SEGMENT_ALIGN in ScriptParser.cpp.

Jul 19 2019, 3:20 AM · Restricted Project

Jul 18 2019

peter.smith added a comment to D64903: [ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with traps only if -z separate-code is specified.

Would it also be possible to define what -zseparate-code is supposed to do in LLD?

Update description to explain -z separate-code

Jul 18 2019, 5:24 AM · Restricted Project
peter.smith added a comment to D64903: [ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with traps only if -z separate-code is specified.

Would it be possible to update the description. It started as why we should not pad the end of the last PF_X program segment, and looks like we have added -z[no-]separate code. Would it also be possible to define what -zseparate-code is supposed to do in LLD? A mini spec I guess. For example should -zno-separate-code affect our default image layout? I'm finding it difficult to check the code without knowing what it is supposed to do.

Jul 18 2019, 3:30 AM · Restricted Project
peter.smith added inline comments to D64880: ELF: Allow forward references to linked sections..
Jul 18 2019, 2:58 AM · Restricted Project
peter.smith accepted D64466: AArch64: Unify relocation restrictions between MOVK/MOVN/MOVZ..

LGTM. I think that the change is worth making as no linker strictly interprets the ABI and checks the instruction encoding, and the calculation is good for all variants. I'm hoping to get the ABI wording relaxed in the next version.

Jul 18 2019, 2:35 AM · Restricted Project

Jul 17 2019

peter.smith added a comment to D64854: [ELF] Delete redundant pageAlign at PT_GNU_RELRO boundaries after D58892.

Currently we align p_vaddr to the next multiple of max-page-size, instead of ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) as ld.bfd does in its -z noseparate-code mode and some cases in its -z separate-code mode. See the comment below for a ld.lld -z max-page-size=0x200000 case:

  [11] .rodata           PROGBITS        0000000000000558 000558 000004 04  AM  0   0  4                        
  [12] .eh_frame_hdr     PROGBITS        000000000000055c 00055c 00002c 00   A  0   0  4                        
  [13] .eh_frame         PROGBITS        0000000000000588 000588 0000cc 00   A  0   0  8             
////// gap due to separated R-- and R-X   
///// This gap can be saved in --no-rosegment mode.   
  [14] .text             PROGBITS        0000000000200000 200000 000161 00  AX  0   0 16                       
  [15] .init             PROGBITS        0000000000200164 200164 000017 00  AX  0   0  4                       
  [16] .fini             PROGBITS        000000000020017c 20017c 000009 00  AX  0   0  4                       
  [17] .plt              PROGBITS        0000000000200190 200190 000020 00  AX  0   0 16 
                      
  [18] .fini_array       FINI_ARRAY      0000000000400000 400000 000008 08  WA  0   0  8                       
  [19] .init_array       INIT_ARRAY      0000000000400008 400008 000008 08  WA  0   0  8                       
  [20] .dynamic          DYNAMIC         0000000000400010 400010 0001a0 10  WA  8   0  8                       
  [21] .got              PROGBITS        00000000004001b0 4001b0 000028 00  WA  0   0  8                       
  [22] .bss.rel.ro       NOBITS          00000000004001d8 4001d8 000000 00  WA  0   0  1         
/// Gap due to PT_GNU_RELRO. It wasts almost 0x200000 bytes.
/// If we change p_vaddr of the RW PT_LOAD from 0x600000 to 0x6001d8, its p_offset doesn't need to be aligned, and we can save nearly 0x200000 bytes in the file.
  [23] .data             PROGBITS        0000000000600000 600000 000010 00  WA  0   0  8                       
  [24] .tm_clone_table   PROGBITS        0000000000600010 600010 000000 00  WA  0   0  8                       
  [25] .got.plt          PROGBITS        0000000000600010 600010 000020 00  WA  0   0  8                       
  [26] .bss              NOBITS          0000000000600030 600030 000001 00  WA  0   0  1

We perform several max-page-size alignments for this file and each costs nearly 0x200000 bytes. If we do the optimization as described in the comment, we can save a lot of disk space. This is particularly relevant to targets with a large defaultMaxPageSize (AArch64, MIPS (@atanasyan), and PPC (@sfertile): 65536).

What do you think of this trick?

Jul 17 2019, 3:20 AM · Restricted Project

Jul 15 2019

peter.smith added a comment to D64466: AArch64: Unify relocation restrictions between MOVK/MOVN/MOVZ..

I think that this is reasonable given that the wording in the ABI was recently changed to relax some of the wording surrounding MOVZ and MOVK. In particular Table 4-7 and Table 4-8 where modified in version E, the latest version is F https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2019q2-documentation

Unfortunately it looks like Table 4-11 and Table 4-12 still have the distinction between MOVZ and MOVK. I think that this is likely an oversight rather than a deliberate decision, but I'd like to check. I'm on holiday this week, so I'll need to wait till Monday to follow this up. I've added a couple of my colleagues who may be able to help in my absence.

Jul 15 2019, 6:53 AM · Restricted Project
peter.smith accepted D64683: MC: AArch64: Add support for prel_g* relocation specifiers..

LGTM

Jul 15 2019, 6:48 AM · Restricted Project
peter.smith added a comment to D64685: ELF: Add support for remaining R_AARCH64_MOVW* relocations..

Functionally looks good. To my eyes it matches what is in the Arm ARM and ELF for the 64-bit architecture:

Jul 15 2019, 4:17 AM · Restricted Project
peter.smith added a comment to D64415: Consistent types and naming for AArch64 target features (NFC).

FWIW I think this looks reasonable. The ARM equivalent uses bitfields such as

unsigned CRC : 1;
unsigned Crypto : 1;
unsigned DSP : 1;
unsigned Unaligned : 1;
unsigned DotProd : 1;

Which would make more sense than using unsigned for each individual field. Several other targets that I looked at used bool and the Has<feature> convention so I think this brings AArch64 more in line with non ARM Targets at the cost of losing a little coherence with ARM where the name Crypto remains. I don't think that this is particularly important as the two have already started to diverge with HasDotProd.

Jul 15 2019, 2:10 AM · Restricted Project

Jul 10 2019

peter.smith added a comment to D64456: ELF: Add support for R_AARCH64_ADR_PREL_PG_HI21_NC relocation..

I've accepted D64455, looks good to me too.

Jul 10 2019, 1:08 AM · Restricted Project
peter.smith accepted D64455: MC: AArch64: Add support for pg_hi21_nc relocation specifier..

Looks good to me. The pg_hi21_nc matches what is used in GNU as. For completeness, at some point we may want to add :pg_hi21: which maps to R_AARCH64_ADR_PREL_PG_HI21 but given that is what we get with no modifier it doesn't seem like it is used in practice.

Jul 10 2019, 1:07 AM · Restricted Project
peter.smith added reviewers for D64466: AArch64: Unify relocation restrictions between MOVK/MOVN/MOVZ.: ostannard, LukeCheeseman.

I think that this is reasonable given that the wording in the ABI was recently changed to relax some of the wording surrounding MOVZ and MOVK. In particular Table 4-7 and Table 4-8 where modified in version E, the latest version is F https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2019q2-documentation

Jul 10 2019, 12:40 AM · Restricted Project

Jul 9 2019

peter.smith added a comment to D64121: Rename variables so that they start with a lowercase letter..

Agreed. I think now is as good a time as any to go for it, LGTM too.

Jul 9 2019, 1:34 AM · Restricted Project

Jul 4 2019

peter.smith accepted D64200: [ELF] Allow placing non-string SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

Based on the closeness to D63432 and Dave's testing LGTM.

Jul 4 2019, 6:23 AM · Restricted Project
peter.smith added a comment to D64200: [ELF] Allow placing non-string SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

That would (1) waste space and (2) create unaligned sections when tail merge (-O2) is enabled. MOVAPS on such unaligned strings can raise SIGSEGV.

I haven't figured out the root cause of (2) yet.

(1) justifies a change, otherwise we will get something like a.......b.......c......., which wastes space.

Jul 4 2019, 5:06 AM · Restricted Project
peter.smith added a comment to D64121: Rename variables so that they start with a lowercase letter..

Thanks for the updates. I've scanned through the whole patch and only 2 things jumped out at me and they are minor and subjective; I've put comments inline. It is certainly possible that I missed something, but overall I think that this is good enough and we could fix up any other mistakes later on.

Jul 4 2019, 3:14 AM · Restricted Project
peter.smith added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

FWIW: The buildbot http://lab.llvm.org:8011/builders/clang-lld-x86_64-2stage/builds/8556/steps/test-stage2-check-all/logs/stdio build did eventually fail with the same errors. I am able to reproduce locally with:

  • Build clang, lld, compiler-rt with this change. Strictly speaking it might be enough to build just LLD, but by doing clang as well it makes stage 2 easier. I used
  • Install (probably not necessary, as this can probably be done out of the build directory)
  • Make new build directory
  • Do ninja check-llvm
Jul 4 2019, 2:57 AM · Restricted Project
peter.smith added a comment to D64136: [ELF] resolveUndefined: ignore undefined symbols in SharedFile for Undefined and SharedSymbol.

Thanks for the update and the extra test. Functionally I think this looks good.

Jul 4 2019, 1:35 AM · Restricted Project

Jul 3 2019

peter.smith added a comment to D64130: [LLD][ELF] - Linkerscript: add a support for expressions for section's filling.

Thanks for the update. Looks ok to me, will be worth seeing what the others say.

Jul 3 2019, 8:57 AM · Restricted Project
peter.smith added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

I can try -M (a.k.a. --print-map). Is there a simple failing test from the LLVM or clang test suite that would be enlightening to try it with?

Unfortunately I don't think so. Given where the test failures are (clang linked with LLD), I think that this may be a problem in the clang executable or shared-library itself causing it to miscompile the tests. If I'm right I think we'll need to find where the differences are in the before and after build then track back to the merge sections in the original objects.

Jul 3 2019, 8:53 AM · Restricted Project
peter.smith added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

I'm trying to think of possible problems that this change could have caused. I think that almost by definition of a merge section, you can't rely on the address of any entry to be unique. The one thing I can think of is something where the alignment requirements are higher than the entry size. By the definition of merge sections this doesn't make a lot of sense to me and might be considered a code-gen or user error.

Jul 3 2019, 8:41 AM · Restricted Project
peter.smith added inline comments to D64136: [ELF] resolveUndefined: ignore undefined symbols in SharedFile for Undefined and SharedSymbol.
Jul 3 2019, 8:34 AM · Restricted Project
peter.smith added a comment to D64130: [LLD][ELF] - Linkerscript: add a support for expressions for section's filling.

It looks like gold and bfd disagree on whether a symbol is allowed in practice.

Jul 3 2019, 7:48 AM · Restricted Project
peter.smith added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

This change breaks a ton of clang tests, albeit in the Swift fork of clang. Was this expected? If not, can we revert this for now?

I've confirmed that reverting this change allows top-of-tree LLVM+clang+lld to build/test top-of-tree Swift (with forks of llvm, clang, etc)

Jul 3 2019, 6:43 AM · Restricted Project
peter.smith added a comment to D64121: Rename variables so that they start with a lowercase letter..

Currently, IS is just renamed is, but variables starting with IS (such as ISAddr) is renamed isecAddr by a special rule. Otherwise it would have looked like a predicate. I made a few special rules other than that, which you can see at https://reviews.llvm.org/D64123 (look for lowercase function).

Jul 3 2019, 3:45 AM · Restricted Project
peter.smith added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

🤖: ping

Jul 3 2019, 2:36 AM · Restricted Project
peter.smith added a comment to D64121: Rename variables so that they start with a lowercase letter..

In general I think a move to camelCase or snake_case is an improvement, don't have a particularly strong opinion over which one. I suspect that the camelCase transition is easier to automate. With just a quick scan of some of the output there are a few cases where some of the variable names are used as acronyms ISD -> InputSectionDescription. Or IS -> InputSection. I don't think that these survive the transition well, in particular IS -> is. I've not got a great idea for what to do about these right now, some possible options:

  • Do the full renaming as above and change the variable names later. Presumably it would help to be consistent.
  • Don't rename common acronyms like IS and change the variable names later.
  • Allow common acronyms to stay capitalised.
  • Have some custom renames for acronyms like IS.

I don't have a particularly strong opinion on which option. It would be helpful to be consistent though.

Jul 3 2019, 2:28 AM · Restricted Project

Jul 2 2019

peter.smith added a comment to D64077: [ELF] Assert sizeof(SymbolUnion) <= 80.

No objections to adding the assert, will be worth adding a bit more context as I can see someone modifying Symbol getting an assert fail and not knowing why the assert is there.

Jul 2 2019, 7:06 AM · Restricted Project

Jul 1 2019

peter.smith added a comment to D63974: [ELF] Only allow the binding of SharedSymbol to change for the first undef ref.

Thanks for the update, looks easier to understand to now.

Jul 1 2019, 9:49 AM · Restricted Project
peter.smith accepted D63826: [docs][llvm-readelf] Expand llvm-readelf documentation.

Thanks for the update. I'm happy with the changes.

Jul 1 2019, 8:06 AM · Restricted Project
peter.smith added inline comments to D63974: [ELF] Only allow the binding of SharedSymbol to change for the first undef ref.
Jul 1 2019, 7:17 AM · Restricted Project

Jun 27 2019

peter.smith added a comment to D63826: [docs][llvm-readelf] Expand llvm-readelf documentation.

I'll post something on the mailing list to see if anybody else has any thoughts.

Done: http://lists.llvm.org/pipermail/llvm-dev/2019-June/133384.html

Jun 27 2019, 4:41 AM · Restricted Project

Jun 26 2019

peter.smith added a comment to D63826: [docs][llvm-readelf] Expand llvm-readelf documentation.

Overall no objections. Only thing I can think of that could be surprising is the presence of mach-o and coff options in llvm-readelf. A case could be made for leaving these out as people migrating won't need to use them, but I don't have a strong opinion.

Jun 26 2019, 9:45 AM · Restricted Project
peter.smith added a comment to D63810: Change the default arm-linux-gnueabihf target to armv7.

The arm1176jfz-s is what is used on the first revision of the Raspberry Pi and I think some of the later reduced size versions. This corresponds to the first mass market ARM linux distribution incorporating HF. Changing the default to ARMv7 would mean that people using clang for a Raspberry Pi using the default would end up with programs that likely would not run due to use of Arm v7 instructions. It is difficult to know how many people actually care about this as I suspect that Distros that still support the first revision of Raspberry Pi can change the default back. I think Sjoerd is right and a question on llvm-dev to canvas opinion would be a good idea.

Jun 26 2019, 2:33 AM · Restricted Project

Jun 25 2019

peter.smith added a comment to D63719: [docs][llvm-readobj] Improve llvm-readobj documentation.

Thanks for the update LGTM too.

Jun 25 2019, 5:45 AM · Restricted Project

Jun 24 2019

peter.smith added a comment to D63719: [docs][llvm-readobj] Improve llvm-readobj documentation.

Thanks for doing this, this is a big improvement. One mild suggestion, but no objections from me.

Jun 24 2019, 9:14 AM · Restricted Project
peter.smith added a comment to D63280: [llvm-objdump] Use <first-symbol>-<offset> as the section start symbol.

To help writing up the discussion thread, I'm trying to gather some data on how each target handle the case with GNU objdump. Weird that I could not reproduce the results @MaskRay @peter.smith was able to obtain. This is not to show favor for either choice but to understand the current situation on GNU side so we make a sensible decision.

Jun 24 2019, 1:58 AM · Restricted Project

Jun 21 2019

peter.smith added a comment to D63280: [llvm-objdump] Use <first-symbol>-<offset> as the section start symbol.

@MaskRay, @peter.smith, is it just the PLT that is specially handled? Perhaps we could just special-case that in llvm-objdump? I think there's clear precedence for this for other versions of objdump, so I'm okay with that difference in behaviour.

It seems to me like other cases of this syntax appearing are going to be very rare overall.

Jun 21 2019, 2:28 AM · Restricted Project
peter.smith added a comment to D63280: [llvm-objdump] Use <first-symbol>-<offset> as the section start symbol.

May I ask you to start a thread on https://lists.llvm.org/pipermail/llvm-dev/2019-June to discuss this?

I agree that this needs a wider audience. @ychen, could you go ahead and start that email, please. Feel free to run a draft by me first if you want.

Jun 21 2019, 1:59 AM · Restricted Project

Jun 18 2019

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

Happy with the changes, thanks for the update.

Jun 18 2019, 9:05 AM · Restricted Project
peter.smith accepted D60927: [llvm-objdump] Switch between ARM/Thumb based on mapping symbols..

Thanks for the update. Looks good to me. I've made one comment about the v7r test but not knowing what the original intention behind the test was I'm not sure if it is worth changing.

Jun 18 2019, 4:13 AM · Restricted Project
peter.smith added a comment to D63432: [ELF] Allow placing SHF_MERGE sections with different alignments into the same MergeSyntheticSection.

A small nit in the test, but otherwise looks good to me.

Jun 18 2019, 2:05 AM · Restricted Project

Jun 17 2019

peter.smith added a comment to D63383: [ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for absolute relocation types in writable sections.

From the Arm and AArch64 side this looks good to me, probably best if the Mips and PPC experts confirm their parts.

Jun 17 2019, 6:28 AM · Restricted Project

Jun 14 2019

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.

Jun 14 2019, 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?

Jun 14 2019, 6:23 AM · Restricted Project, lld