Page MenuHomePhabricator
Feed Advanced Search

Today

psmith committed rG2539b4ae4765: [LLD][ELF] Allow empty (.init|.preinit|.fini)_array to be RELRO (authored by psmith).
[LLD][ELF] Allow empty (.init|.preinit|.fini)_array to be RELRO
Tue, Mar 31, 5:00 AM
psmith closed D76915: [LLD][ELF] Allow empty (.init|.preinit|.fini)_array to be RELRO.
Tue, Mar 31, 5:00 AM · Restricted Project

Yesterday

psmith updated the diff for D76915: [LLD][ELF] Allow empty (.init|.preinit|.fini)_array to be RELRO.

Thanks for the comments, I've added some tests to check that the _array sections are zero size, also to show the extent of the RELRO includes the section before and after.

Mon, Mar 30, 10:16 AM · Restricted Project
psmith accepted D77007: [ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER to be mixed.

I agree that there is no reason not to support the mixing of SHF_LINK_ORDER and non SHF_LINK_ORDER in the same OutputSection. Arm's proprietary linker will handle .ARM.exidx that way, I believe that a separate OutputSection is used in GNU ld and LLD as it simplifies the generation of Linker Generated Symbols that the library uses to find the tables.

Mon, Mar 30, 9:10 AM · Restricted Project
psmith added a comment to D76410: [ELF] Don't combine SHF_LINK_ORDER sections linking different output sections.

Reading the comprehensive feedback, I think we should make this change. There are probably really two difference uses of SHF_LINK_ORDER: one is monolithic (__start_/DT_INIT_ARRAY/...) and the other is not (__patchable_function_entries/.stack_sizes). If pcc has future monolithic use cases, we can cross the bridge when we come to it.

Mon, Mar 30, 8:37 AM · Restricted Project
psmith added a comment to D76995: [ELF] Propagate LMA offset to sections with neither AT() nor AT>.

I think there may be one case from ld that we aren't handling, and I've made a few suggestions for the documentation, otherwise looks like a good step in the right direction.

Mon, Mar 30, 8:03 AM · Restricted Project

Fri, Mar 27

psmith created D76915: [LLD][ELF] Allow empty (.init|.preinit|.fini)_array to be RELRO.
Fri, Mar 27, 3:44 AM · Restricted Project

Thu, Mar 26

psmith added a comment to D76765: [LLD][ELF] - Linkerscript: support the case when INPUT_SECTION_FLAGS is used without section patterns..
The raw wildcard syntax is questionable because it can potentially cause parsing ambiguity.

...
I also left a comment on https://bugs.llvm.org/show_bug.cgi?id=39885

What about if we drop the following piece we have then?

} else {
  // We have a file name and no input sections description. It is not a
  // commonly used syntax, but still acceptable. In that case, all sections
  // from the file will be included.
  // FIXME: GNU ld permits INPUT_SECTION_FLAGS to be used here. We do not
  // handle this case here as it will already have been matched by the
  // case above.
  auto *isd = make<InputSectionDescription>(tok);
  isd->sectionPatterns.push_back({{}, StringMatcher("*")});
  cmd->sectionCommands.push_back(isd);
}
Thu, Mar 26, 2:07 AM
psmith added a comment to D76746: [MC][ARM] Make .reloc support arbitrary relocation types.

Thanks for the update. I'm happy with the new comments.

Thu, Mar 26, 2:07 AM · Restricted Project

Wed, Mar 25

psmith added a comment to D76765: [LLD][ELF] - Linkerscript: support the case when INPUT_SECTION_FLAGS is used without section patterns..

I've made a comment about potentially allowing nested KEEP, although I'm not 100% sure about it. Other than that this looks good.

Wed, Mar 25, 10:15 AM
psmith added a comment to D76575: [LLD][ELF][ARM] Replace assembler files with yaml.

Thanks for the comments, I'll do my best to trim down the yaml and resubmit tomorrow.

Wait. Sorry that I only recalled the .reloc directive after you had started to work on yaml2obj tests. In an assembly test, a .section directive corresponds to several lines in a YAML. A symbol requires one or two lines in an assembly while it may require up to 5 lines in a YAML.

I created D76746 to generalize .reloc. With this patch, we can probably write:

.globl bar
bar:
adr r0, bar; .reloc 0, R_ARM_ALU_PC_G0, bar
Wed, Mar 25, 2:08 AM
psmith added a comment to D76746: [MC][ARM] Make .reloc support arbitrary relocation types.

I think this could work, I've got a few comments on the generic part, but otherwise looks reasonable to me. Would be nice to extend this to AArch64 as there are some relocs that GCC/GNU as can emit that llvm-mc does not and it would be good to support these in LLVM.

Wed, Mar 25, 1:35 AM · Restricted Project

Tue, Mar 24

psmith added a comment to D76575: [LLD][ELF][ARM] Replace assembler files with yaml.

Thanks for the comments, I'll do my best to trim down the yaml and resubmit tomorrow.

Tue, Mar 24, 2:39 AM
psmith added a comment to D76410: [ELF] Don't combine SHF_LINK_ORDER sections linking different output sections.

Thinking about this a bit more, this is my opinion.

Tue, Mar 24, 2:39 AM · Restricted Project

Sun, Mar 22

psmith added a comment to D72892: [MC][ARM] Resolve some pcrel fixups at assembly time.

I've created a review to change the existing LLD Thumb relocations to obj2yaml with D76575

Sun, Mar 22, 3:01 PM · Restricted Project
psmith created D76575: [LLD][ELF][ARM] Replace assembler files with yaml.
Sun, Mar 22, 3:01 PM

Fri, Mar 20

psmith added a comment to D76410: [ELF] Don't combine SHF_LINK_ORDER sections linking different output sections.

I don't have any more comments. I think the change is reasonable for orphan sections, happy for George to approve if he is happy his last comments are addressed.

Fri, Mar 20, 8:05 AM · Restricted Project

Thu, Mar 19

psmith added a comment to D76410: [ELF] Don't combine SHF_LINK_ORDER sections linking different output sections.

Given the somewhat loose definition in ELF

This flag adds special ordering requirements for link editors. The requirements apply if the sh_link field of this section's header references another section (the linked-to section). If this section is combined with other sections in the output file, it must appear in the same relative order with respect to those sections, as the linked-to section appears with respect to sections the linked-to section is combined with.
NOTE: A typical use of this flag is to build a table that references text or data sections in address order.

In the text below, a generic SHF_LINK_ORDER section is just a section we haven't identified as needing any special requirements and only demands what it is written in the ELF spec. A non-generic SHF_LINK_ORDER section like .ARM.exidx has additional requirements on top of generic ELF, for example from the ARM ABI documentation.

Thu, Mar 19, 2:39 AM · Restricted Project

Mon, Mar 16

psmith added a comment to D75349: [LLD][ELF][ARM] Implement ARM pc-relative relocations for adr and ldr.

The assembly tests should be rewritten as yaml2obj because we will either resolve/reject such short-range fixups in MC.

Mon, Mar 16, 9:48 AM · Restricted Project

Sun, Mar 15

psmith added a comment to D72892: [MC][ARM] Resolve some pcrel fixups at assembly time.

Oh, if binutils is assuming the symbol isn't preemptible, there isn't much point to generating the relocation and waiting for the linker to resolve it; we should just resolve it the same way in the assembler.

Sun, Mar 15, 12:51 PM · Restricted Project
psmith added a comment to D76174: [ELF] Support linking ET_EXEC.

I can see that this would work if the user were very careful and as it is a legitimate use case we should support it. In a previous linker we were asked to make this case an error as a customer had done this by mistake and spent several hours wondering why their program wasn't working. On balance I think it isn't worth a warning along the lines of "warning: file X is an executable" as I don't think that this happens much in practice, but something to think about if other users have problems.

Sun, Mar 15, 3:43 AM · Restricted Project

Wed, Mar 11

psmith added a comment to D75966: [ELF] Move --print-map(-M)/--cref before checkSections() and openFile().

So, is the patch good to go as-is? :)

Wed, Mar 11, 3:19 PM · Restricted Project
psmith added a comment to D75966: [ELF] Move --print-map(-M)/--cref before checkSections() and openFile().

I'm not suggesting we make -M display on every error. It was just mentioning experience of a linker that does do that when the map file is enabled, which approximates what you have here. I think this is good logical step to take, and if we need to alter it later after we gain experience we can do.

Wed, Mar 11, 1:01 PM · Restricted Project
psmith accepted D75724: [ELF] Simplify sh_addr computation and warn if sh_addr is not a multiple of sh_addralign.

Now that we have some documentation in place to record the decision, and I've not seen any objections to the simplification, I'm happy to approve the change.

Wed, Mar 11, 5:08 AM · Restricted Project
psmith added inline comments to D75966: [ELF] Move --print-map(-M)/--cref before checkSections() and openFile().
Wed, Mar 11, 5:08 AM · Restricted Project
psmith committed rG6d5603e2d220: [LLD][ELF] Add initial LLD LinkerScript docs page (authored by psmith).
[LLD][ELF] Add initial LLD LinkerScript docs page
Wed, Mar 11, 4:33 AM
psmith closed D75921: [LLD][DOCS][ELF]Add initial LLD LinkerScript docs page.
Wed, Mar 11, 4:30 AM · Restricted Project

Tue, Mar 10

psmith updated the diff for D75921: [LLD][DOCS][ELF]Add initial LLD LinkerScript docs page.

Thanks for spotting that. I've used the same style as the other file. I've checked the resulting html and link works.

Tue, Mar 10, 8:39 AM · Restricted Project
psmith added a comment to D75724: [ELF] Simplify sh_addr computation and warn if sh_addr is not a multiple of sh_addralign.

Created D75921 to create the initial contents of linker_script.rst
While trying to build it I ran into https://bugs.llvm.org/show_bug.cgi?id=41789 as I had too new a version of Sphinx. The solution in the PR worked for the LLD docs, although the overall LLVM docs build failed for a different (deprecation of something in latest Sphinx) in an unrelated file. If this happens to you I suggest setting SPHINX_EXECUTABLE=/path/to/pre_2.0_sphinx_build in your cmake command.

Tue, Mar 10, 7:31 AM · Restricted Project
psmith created D75921: [LLD][DOCS][ELF]Add initial LLD LinkerScript docs page.
Tue, Mar 10, 7:00 AM · Restricted Project

Mon, Mar 9

psmith added a comment to D75724: [ELF] Simplify sh_addr computation and warn if sh_addr is not a multiple of sh_addralign.

Thanks for the documentation! I think the paragraphs may be too long for docs/ld.lld.1. May I suggest you create a patch to add Linker Script implementation notes and policy to docs/ELF/linker_script.rst? I can add Output Section ALIGN in this patch. I don't want to take credit for the important policy part.

Mon, Mar 9, 2:03 PM · Restricted Project

Sun, Mar 8

psmith added a comment to D75724: [ELF] Simplify sh_addr computation and warn if sh_addr is not a multiple of sh_addralign.

If the ld.bfd developers consider both [address] and [ALIGN(section_align)] as undefined behaviour then I'm happy that we can simplify and the above change does implement that. Would like to hear what some of the other reviewers think as well.

Sun, Mar 8, 9:03 AM · Restricted Project

Fri, Mar 6

psmith added inline comments to D75347: [MC][ELF][ARM] Add relocations for some ARM pc-relative fixups..
Fri, Mar 6, 11:35 AM · Restricted Project
psmith added a comment to D75724: [ELF] Simplify sh_addr computation and warn if sh_addr is not a multiple of sh_addralign.

In theory I don't mind that we deviate from GNU ld where it makes sense, however given that our Linker Script documentation is the GNU ld docs, and that has considerable gaps, I'd be much more comfortable in approving if we had more user facing documentation where we document the differences. I know that this has come up before but we didn't take any action. Is it worth starting now, even if we only document this one difference and add to it over time? This could either be in our existing man page and/or in the official LLVM docs.

Fri, Mar 6, 9:53 AM · Restricted Project
psmith added a comment to D72892: [MC][ARM] Resolve some pcrel fixups at assembly time.

Emitting the relocations seems conceptually sound: the cases that make sense work, and the linker emits a reasonable error for the cases that don't. My concern is that the user is likely to get a weird error message if they use a non-lld linker. What do GNU linkers print?

In a shared object with a global preemptible definition of X, ld.bfd will resolve the adr and ldr relocations with respect to X, and not any PLT or GOT entry for X. If X is in range this will be the same behaviour as if the assembler resolves the relocation. If X is too far away there will be an out of range error. A disadvantage of emitting a relocation is that instead of a cryptic assembler error message, we get a relocation out of range error message. This isn't ideal as the error is delayed to link time.

Fri, Mar 6, 5:31 AM · Restricted Project

Tue, Mar 3

psmith added a comment to D72892: [MC][ARM] Resolve some pcrel fixups at assembly time.

My personal view is that we should be able to support adr and ldr to a global symbol defined in the same section, whether at link time or at assembly time. As well as Linux, Android and BSD there is large number of embedded systems that use assembler and are entirely statically linked that we risk breaking without a good error message. I would like to avoid that situation if at all possible. I don't think we need to support adr and ldr to symbols defined outside the section as the range is too short to practically use them.

Tue, Mar 3, 2:09 AM · Restricted Project

Mon, Mar 2

psmith added reviewers for D75428: [MC][ARM] add implicit immediate form for ldrsbt/ldrht/ldrsht: ostannard, eli.friedman.

Adding some more reviewers. I'm not aware of any hard and fast rule as to when to use a new instruction or an alias, I think it is a case by case decision, although people more familiar with tablegen may know otherwise.
I'd prefer a solution where the disassembly of ldrsht r5, [r6] is either ldrsht r5, [r6] or ldrsht r5, [r6], #0. ldrsht r5, [r6], #-0 is legal but not really canonical, maybe always set the U bit (23) to make the immediate positive.

Mon, Mar 2, 2:04 AM · Restricted Project

Feb 28 2020

psmith added a comment to D72892: [MC][ARM] Resolve some pcrel fixups at assembly time.

With luck after the following couple of patches for Arm state, we'll output relocations for these fixups when there is a global symbol, and as a bonus get to support cross-section references if they happen to be within the range of the relocations. At link time it will be possible to determine whether a symbol is interposed and possibly warn or error for problem cases in shared objects while accepting cases in executables.
https://reviews.llvm.org/D75347 (MC)
https://reviews.llvm.org/D75349 (LLD)
My apologies for any problems caused, I do want to have adr and ldr to global symbols be allowed for executables.

Feb 28 2020, 9:01 AM · Restricted Project
psmith created D75349: [LLD][ELF][ARM] Implement ARM pc-relative relocations for adr and ldr.
Feb 28 2020, 6:39 AM · Restricted Project
psmith added a child revision for D75347: [MC][ELF][ARM] Add relocations for some ARM pc-relative fixups.: D75349: [LLD][ELF][ARM] Implement ARM pc-relative relocations for adr and ldr.
Feb 28 2020, 6:39 AM · Restricted Project
psmith created D75347: [MC][ELF][ARM] Add relocations for some ARM pc-relative fixups..
Feb 28 2020, 5:53 AM · Restricted Project
psmith committed rG1b025665c93b: [ELF][LLD][ARM] Add missing REQUIRES: arm to tests (authored by psmith).
[ELF][LLD][ARM] Add missing REQUIRES: arm to tests
Feb 28 2020, 3:53 AM
psmith committed rG2a92fc9b8e6a: [MC][ELF][ARM] Add relocations for some pc-relative fixups (authored by psmith).
[MC][ELF][ARM] Add relocations for some pc-relative fixups
Feb 28 2020, 3:34 AM
psmith committed rG6b035b607f5f: [LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr (authored by psmith).
[LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr
Feb 28 2020, 3:34 AM
psmith added a reverting change for D72892: [MC][ARM] Resolve some pcrel fixups at assembly time: rG2a92fc9b8e6a: [MC][ELF][ARM] Add relocations for some pc-relative fixups.
Feb 28 2020, 3:34 AM · Restricted Project
psmith closed D75042: [LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr.
Feb 28 2020, 3:34 AM · Restricted Project
psmith closed D75039: [MC][ELF][ARM] Add relocations for Thumb pc-relative fixups.
Feb 28 2020, 3:34 AM · Restricted Project
psmith updated the diff for D75039: [MC][ELF][ARM] Add relocations for Thumb pc-relative fixups.

Rebased after D72892 landed for the benefit of the 10.0 release as discussed in pr44929. This effectively reverts the Thumb side of that patch as well as enabling the relocations. The ARM side of D72892 is still there as LLD hasn't implemented the relocations yet. Will post patch for that shortly.

Feb 28 2020, 3:24 AM · Restricted Project

Feb 27 2020

psmith added a comment to D72892: [MC][ARM] Resolve some pcrel fixups at assembly time.

I intended this to be committed to release/10.x only, but it is now also in master... commit 2e24219d3cbfcb8c824c58872f97de0a2e94a7c8

Feb 27 2020, 9:29 AM · Restricted Project
psmith added inline comments to D75216: [lld][ELF] Add some release notes.
Feb 27 2020, 8:35 AM · Restricted Project
psmith added a comment to D75216: [lld][ELF] Add some release notes.

Thanks for taking the lead on this. I've put a few suggestions for some cosmetic changes.

Feb 27 2020, 4:37 AM · Restricted Project
psmith added a comment to D75225: [ELF] Keep orphan section names (.rodata.foo .text.foo) unchanged if !hasSectionsCommand.

I'm happy to make the change, although orphan section placement is documented to be linker's choice it will help people needing support in ld.bfd and lld if we have similar rules.

Feb 27 2020, 2:21 AM · Restricted Project

Feb 26 2020

psmith added a comment to D74687: [LLD][ELF] - Disambiguate "=fillexp" with a primary expression to allow =0x90 /DISCARD/.

Would it make sense to make /DISCARD/ its own token recognised by the Lexer? I believe that is what BFD does. It would prevent it from being recognised as "/" "DISCARD" "/". Apologies if this is not appropriate, I'm not too familiar with this part of the code.

Feb 26 2020, 3:48 AM · Restricted Project
psmith added inline comments to D75042: [LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr.
Feb 26 2020, 2:50 AM · Restricted Project
psmith added a comment to D75039: [MC][ELF][ARM] Add relocations for Thumb pc-relative fixups.

Thanks, I'll wait for the LLD review that implements the relocations (D75042) before committing.

Feb 26 2020, 2:50 AM · Restricted Project
psmith added a comment to D75144: [ARM][Thumb2] Support .w assembler qualifier for pld/pldw/pli.

ps. I'm quite happy, with ostannard approving.

Feb 26 2020, 2:11 AM · Restricted Project
psmith added reviewers for D75144: [ARM][Thumb2] Support .w assembler qualifier for pld/pldw/pli: momchil.velikov, eli.friedman, jcai19.

The change looks good to me, but I'm far from an expert on tablegen. There is a similar revision for ldrb.w under D68916 I've added reviewers that have been involved there to see if they have any thoughts on the approach.

Feb 26 2020, 2:10 AM · Restricted Project
psmith added a comment to D74927: [MC][ARM] make Thumb function also if type attribute is set.

The mapping symbols $a, $t and $d are emitted whenever there is a state change. See the EmitMappingSymbol() functions in ARMELFStreamer.cpp . As an example:

Feb 26 2020, 1:59 AM · Restricted Project

Feb 25 2020

psmith added a comment to D74927: [MC][ARM] make Thumb function also if type attribute is set.

The rules seem complex and error-prone. Are these any cases we should emit a warning? Will be nice to communicate that with binutils people as well.

Strictly speaking I'd say that the only explicit contradiction is where .thumb_func is used and yet the state is actually ARM. When .type symbol, %function is used, the user is implicitly relying on the Assembler to set the type of the symbol appropriately. If the assembler knows enough to warn then it knows enough to set the type of the symbol correctly. This requires a bit more tracking of state than the current rather arbitrary set of heuristics that both GNU as and MC are using. Actual practical usage of state changes are small as most files tend to be entirely Arm or entirely Thumb so the simple heuristics work for 99% of the cases. In practice I suspect that using a similar set of heuristics in both GNU and LLVM will aid portability, this would mean warning if the assembler detected that the ARM/Thumb state of the symbol disagreed with the ARM/Thumb state of the mapping symbols.

Feb 25 2020, 10:18 AM · Restricted Project
psmith added a comment to D74927: [MC][ARM] make Thumb function also if type attribute is set.

I think using .type symbol, %function is more common when a file has to assemble in both Arm or Thumb state depending on whether -marm or -mthumb is given to the assembler.

Feb 25 2020, 9:42 AM · Restricted Project
psmith updated the diff for D75042: [LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr.

Thanks for the comments, I've removed the checks for Symbol being nullptr, these could exist if we were to call with relocateNoSym, but we don't do that at present. Removed -n and used /dev/null in all error tests.

Feb 25 2020, 7:48 AM · Restricted Project
psmith updated the diff for D75039: [MC][ELF][ARM] Add relocations for Thumb pc-relative fixups.

Thanks for the comments, I've added the missing test, and updated the description with the mapping from fixup_t2_adr_pcrel_12 -> R_ARM_THM_PREL_11_0

Feb 25 2020, 7:24 AM · Restricted Project

Feb 24 2020

psmith added reviewers for D74927: [MC][ARM] make Thumb function also if type attribute is set: ostannard, eli.friedman.

I think you'll need to rebase and change to emitSymbolAttribute. I also think we could do with a comment. Other that that I think this is looking good. Adding some more reviewers to see if there are any objections, or alternative suggestions. Personally I'm inclined to accept as we get the following case wrong in the linux kernel (https://github.com/torvalds/linux/blob/master/arch/arm/kernel/entry-common.S) which has an idiom:

label:
   ...
   ENDPROC(label)

Where the ENDPROC has the .type label, %function

Feb 24 2020, 1:16 PM · Restricted Project
psmith added a parent revision for D75042: [LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr: D75039: [MC][ELF][ARM] Add relocations for Thumb pc-relative fixups.
Feb 24 2020, 5:01 AM · Restricted Project
psmith created D75042: [LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr.
Feb 24 2020, 5:01 AM · Restricted Project
psmith added a child revision for D75039: [MC][ELF][ARM] Add relocations for Thumb pc-relative fixups: D75042: [LLD][ELF][ARM] Implement Thumb pc-relative relocations for adr and ldr.
Feb 24 2020, 5:01 AM · Restricted Project
psmith created D75039: [MC][ELF][ARM] Add relocations for Thumb pc-relative fixups.
Feb 24 2020, 4:51 AM · Restricted Project

Feb 21 2020

psmith accepted D73999: [MC][ELF] Error for sh_type, sh_flags or sh_entsize change.

Thanks for sending the heads up message. I see no-one has objected (yet), I've marked as approved as I think it is worth going ahead. Will be worth giving some time, end of today perhaps, for others to respond before committing.

Feb 21 2020, 6:06 AM · Restricted Project
psmith accepted D72892: [MC][ARM] Resolve some pcrel fixups at assembly time.

Rebase.

In case someone needs this workaround before we implement these relocations.

Feb 21 2020, 3:50 AM · Restricted Project

Feb 20 2020

psmith added a comment to D73999: [MC][ELF] Error for sh_type, sh_flags or sh_entsize change.

I'm a little surprised at different section attributes being considered a warning given previous comments that users often get this wrong, but the GNU as commit does indeed error so I think it will be better to be consistent. I tend towards putting in the effort to get a better error message, yes experienced assembler writers will know what to do, but these people aren't always the ones looking at build failures from CI. With some extra context we could save quite a lot of people a little bit of time. One possible approach would be to see what the impact is on the projects that build from tip of trunk or close to it and proceed according to feeedback.

Feb 20 2020, 10:56 AM · Restricted Project

Feb 19 2020

psmith added a comment to D74736: [ELF] Ignore the maximum of input section alignments for two cases.

Thanks for the update, I'm happy if George is.

Feb 19 2020, 11:28 AM · Restricted Project
psmith added inline comments to D74736: [ELF] Ignore the maximum of input section alignments for two cases.
Feb 19 2020, 11:09 AM · Restricted Project
psmith added a comment to D74736: [ELF] Ignore the maximum of input section alignments for two cases.

I agree with the specification of the change, I'm not sure why there is a change in Writer.cpp yet, if there is a good reason and it isn't obvious it will be worth a comment.

Feb 19 2020, 10:01 AM · Restricted Project
psmith added a comment to D74741: [ELF] Warn changed output section address.

Thanks for clarifying, I don't have any more comments, happy if George is.

Feb 19 2020, 9:21 AM · Restricted Project
psmith accepted D74827: [LLD][ELF][ARM] Add test cases for R_ARM_THM_MOV*-type relocs.

Thanks for the patch, and for splitting these out from D74604.

Feb 19 2020, 9:12 AM · lld, Restricted Project
psmith committed rG6e326882dadd: [LLD][ELF][ARM] Fix support for SBREL type relocations (authored by tamas.petz).
[LLD][ELF][ARM] Fix support for SBREL type relocations
Feb 19 2020, 2:13 AM
psmith closed D74604: [LLD][ELF][ARM] Fix support for SBREL type relocations.
Feb 19 2020, 2:13 AM · Restricted Project, lld

Feb 18 2020

psmith added a comment to D74741: [ELF] Warn changed output section address.

Just had some thoughts on what values we warn, and what value we give as the original.

Feb 18 2020, 7:30 AM · Restricted Project

Feb 17 2020

psmith added reviewers for D74604: [LLD][ELF][ARM] Fix support for SBREL type relocations: grimar, MaskRay.

The code changes look good to me. I'm unfortunately going to have be a pain and ask that you split the additional tests not related to the new relocation support into a separate change, something like "[LLD][ELF][ARM] add missing test cases for ... " that I'd be happy to approve. This helps keep tracking down failures via bisection easier.

Feb 17 2020, 11:07 AM · Restricted Project, lld

Feb 14 2020

psmith added a comment to D74006: [MC][ELF] Make linked-to symbol name part of ELFSectionKey.

I'm happy with this patch, I think it is a fair reflection of the consensus, I'll let others approve when they have had a chance to read through in the US timezone.

Feb 14 2020, 11:07 AM · Restricted Project
psmith added a comment to D74604: [LLD][ELF][ARM] Fix support for SBREL type relocations.

Thanks for the patch, I'll aim to take a look early next week, hopefully Monday.

Feb 14 2020, 8:23 AM · Restricted Project, lld

Feb 12 2020

psmith accepted D74286: [ELF] Respect output section alignment for AT> (non-null lmaRegion).

OK, the overalignment is one of those don't care for the vast majority of users, and really important to a small number of people. It most often causes a problem when something is heavily aligned in VMA, but as it is copied from ROM/Flash its alignment doesn't matter in LMA.
Anyhow if it is something we can look at fixing later then LGTM as this will solve the immediate problem.

Feb 12 2020, 7:55 AM · Restricted Project
psmith added a comment to D74286: [ELF] Respect output section alignment for AT> (non-null lmaRegion).

OK, to check my understanding. Tracing through that bit of BFD code it seems like in the absence of ALIGN_WITH_INPUT the VMA is aligned to the OutputSection alignment when:

  • (os->addr_tree) // output_section_address is specified
  • if (os->lma_region != os->region) section_alignment = exp_get_power (os->section_alignment, "section alignment");

In all other cases it uses the max of input section alignment. With ALIGN_WITH_INPUT we force the use of dotdelta, which is align by the same alignment as the dot got aligned. I think that this is subtly different to the section alignment as the VMA and LMA could start from different bases.

Feb 12 2020, 4:05 AM · Restricted Project
psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

I asked because I wonder whether a warning is the right approach. GNU ld does not warn. If the projects that are affected is just Chromium, do we still need a warning? It seems @thakis has already fixed the bug.
A warning can help users catch bugs, but it can also make a user with a legitimate use case frustrated.

Feb 12 2020, 2:16 AM · Restricted Project

Feb 11 2020

psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

I have some questions. Are the two warnings added for migration convenience for some projects? Are they still useful after the migration? Do they have false positives? i.e. Is it not allowed to emit BLX referencing a Thumb STT_NONE symbol in ARM state? Is it not allowed to emit BL referencing an ARM STT_NONE symbol in Thumb state? If there are legitimate use cases, will the warnings break their builds if they are configured with -Wl,--fatal-warnings?

Feb 11 2020, 3:44 PM · Restricted Project
psmith added a comment to D74286: [ELF] Respect output section alignment for AT> (non-null lmaRegion).

Looks good? :)

Feb 11 2020, 11:10 AM · Restricted Project
psmith added a comment to D74375: [ELF] Support INSERT [AFTER|BEFORE] for orphan sections.

Thanks for the update, I'm fine with this as well.

Feb 11 2020, 9:57 AM · Restricted Project
psmith accepted D73904: [clang] stop baremetal driver to append .a to lib.

Thanks for the update, looks good to me. The BareMetal driver tests are better than the location I suggested.

Feb 11 2020, 8:17 AM · Restricted Project
psmith accepted D74297: [ELF] Start a new PT_LOAD if LMA region is different.

Thanks for the update, looks good to me.
Some suggestions for the expression, not sure if they are better or not, so by all means keep the original if you prefer.

Feb 11 2020, 7:05 AM · Restricted Project
psmith added inline comments to D74375: [ELF] Support INSERT [AFTER|BEFORE] for orphan sections.
Feb 11 2020, 5:25 AM · Restricted Project
psmith added a comment to D74339: Make .rodata* and .eh_frame* the last of all PROGBITS sections..

Created D74375 . I think INSERT [AFTER|BEFORE] is a great solution to this kind of problems..

Feb 11 2020, 4:49 AM · Restricted Project

Feb 10 2020

psmith added a comment to D73999: [MC][ELF] Error for sh_type, sh_flags or sh_entsize change.

Address review comments.

I tend to agree with Alan Modra's arguement in
https://sourceware.org/ml/binutils/2020-02/msg00093.html

I don't think so. User assembly often gets section attributes wrong
or leaves them off entirely for special sections known to the
assembler. ie. the first .section .foo above is a built-in rather
than user input.

Add more folks for feedback.

Please see my binutils post. For a .section directive with the same name but a different field. If the field is:

  • sh_flags or sh_type: warn
  • sh_link due to SHF_LINK_ORDER: no warning. produce separate sections
  • sh_entsize due to SHF_MERGE: still controversial
Feb 10 2020, 3:50 AM · Restricted Project
psmith added a comment to D74297: [ELF] Start a new PT_LOAD if LMA region is different.

Change looks good to me. Some small nits.

Feb 10 2020, 3:32 AM · Restricted Project
psmith added a comment to D74286: [ELF] Respect output section alignment for AT> (non-null lmaRegion).

Do you happen to know how this relates to the ALIGN_WITH_INPUT linker script keyword? Apologies I've got stuck in an airport due to flight cancellations and can't check easily. I had thought that in BFD if you wanted InputSection alignment to affect LMA you needed to add ALIGN_WITH_INPUT.

Feb 10 2020, 2:11 AM · Restricted Project

Feb 8 2020

psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

Thanks for checking out the problem. I agree that this is a change in behaviour that isn't obvious to new authors of Arm assembler, and we have enough of a legacy of binaries that other people may be affected.

Feb 8 2020, 1:00 AM · Restricted Project

Feb 7 2020

psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

Yup, it bisected to this change as well.

It's now in a much bigger binary and analysis will probably take a bit longer than last time.

Would you mind reverting this while we figure out what exactly is going on? We haven't had a working trunk version in over a week now, and it'd be good if we could update chromium's llvm to make sure there are no other new regressions.

Feb 7 2020, 5:27 AM · Restricted Project

Feb 5 2020

psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

I am also investigating it, calls to the undefined weak getauxval need to use BLX. I'll try fixing it.

Feb 5 2020, 1:58 PM · Restricted Project
psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

I know what the problem is, it is a stupid typo on my part that looks superficially correct and the non-strong enum hasn't saved me at the type checker.

bool interwork = (rel.sym && rel.sym->isFunc()) || rel.type == R_PLT_PC;

Spot the deliberate mistake, this should be rel.expr == R_PLT_PC. There is a similar error at the R_ARM_CALL change, but we are saved by ARM state to ARM state being correct with the non-interwork case. So this needs two changes and a test. I can do this tomorrow morning, but given the possible delay in getting the patch approved, I still think reverting and I'll resubmit makes sense as I don't trust myself with detail this late.

Feb 5 2020, 1:21 PM · Restricted Project
psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

My apologies for the breakage.

Feb 5 2020, 1:03 PM · Restricted Project
psmith added a comment to D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols..

https://bugs.chromium.org/p/chromium/issues/detail?id=1047531#c19 anc #c20 suggest that no assembly is involved and that this instead related to jumps to attribute((weak)) functions.

Feb 5 2020, 1:03 PM · Restricted Project