Peter Smith via llvm-dev
2017-Apr-04 12:12 UTC
[llvm-dev] [LLVM-DEV][LLD] RFC Range Thunks Implementation review for ARM and Mips
This RFC is primarily to support the review of the range extension thunks implementation of lld. This concerns ARM and Mips as all of the thunk creation step is skipped over if the target doesn't need thunks. Mips LA25 Thunks are not range extension Thunks but these are generated using the same code, I've kept the behaviour the same as it is now, although the implementation is obviously slightly different in the detail. Recap of range extension thunks - Many architectures with fixed instruction width have a branch instruction that has a limited range - On ARM and AArch64 the static linker is expected to insert range extension thunks when some classes of branch instruction are out of range Where are we now with LLD and thunks - We have moved the createThunks() function as late as it can be in finalizeSections(), most importantly after all the content has been added to the image. - We only call createThunks() once and we don't calculate addresses before createThunks(). - If an OutputSection is described by a LinkerScript then any thunks created in it are put at the end of the OutputSection. This is due to the LinkerScript not being aware of the thunks (InputSections) in the InputSectionDescriptions. Proposed implementation for range extension thunks At a high-level we need to solve the following problems: - Assign addresses more than once - Maintain state between successive calls of createThunks() - Synchronization of the linker script and the OutputSection after adding thunks - Deciding when we need a range extension thunk and where to place it so that it can be reused by multiple callers. The first 3 problems are where range extension thunks interact most with the rest of the linker. The last problem can be confined to the thunk implementation. Address Assignment The non-linker script address assignment can already be called multiple times. The linker script address assignment records state as it goes, if this state is reset it can be called more than once. Maintaining state between successive calls to createThunks() I've chosen to introduce a class ThunkCreator that can maintain the state between calls. Synchronization of OutputSection and linker scripts An OutputSection described by a linker script SECTIONS command has one or more InputSectionDescriptions that control how InputSections are laid out in that OutputSection. If a thunk section is added to OutputSection.Sections it must be added to the correct InputSectionDescription. For the implementation I have chosen to add Thunks to OutputSection.Sections and then merge these into the InputSectionDescriptions for the OutputSection. Placement of range extension thunks I have chosen a simple implementation of spacing ThunkSections a Target dependent distance apart. For ARM (lld currently supports v7a) this is set to the Thumb2 branch range of 16Mb. If a thunk cannot be created in one of these spaced out ThunkSections a new ThunkSection is created. This allows special cases such as the Thumb2 conditional branch with a range of 1Mb to be supported without reducing the spacing of the pool. This is a different approach to ld.bfd and gold, in gold at least a thunk (Stub) must be placed within one of the precreated ThunkSections, these are called stub groups. There is a command line option --stub-group-size that allows the user some kind of control over the spacing. I've not implemented the command-line option in the initial implementation. Reviews: I've created reviews for a series of patches that implement range extension thunks, I expect that these will need quite a bit of work, especially the first three. If you've got any comments on the code, or anything local to the patch I'd be grateful if you could leave a comment on the relevant review. If there is anything more general then responding to this message may be better. The majority of the actual work is writing the tests, which should be resusable however the implementation ends up. The following patches are the glue code needed for range extension thunks to be implemented. [LLD][ELF] Make createThunks a class [NFC] https://reviews.llvm.org/D31654 [LLD][ELF] Fix Thunks with placement restrictions and linker scripts https://reviews.llvm.org/D31656 [LLD][ELF] Make createThunks() iterate until no more thunks added https://reviews.llvm.org/D31657 The following set of patches add range extension thunks, they are split up to make reviewing easier, but don't add enough to add tests until late on. [ELF] Introduce Thunk reuse compatibility https://reviews.llvm.org/D31658 [ELF] Be more precise about Thumb state bit in ARM thunks https://reviews.llvm.org/D31659 [ELF] Allow multiple thunks to be added for a symbol https://reviews.llvm.org/D31660 [ELF] Pre-create ThunkSections at Target specific intervals https://reviews.llvm.org/D31661 [ELF] Introduce range extension thunks for ARM https://reviews.llvm.org/D31662 [ELF] Account for range thunk that has drifted out of range https://reviews.llvm.org/D31663 [ELF] Prefer placing ThunkSections before non ThunkSections https://reviews.llvm.org/D31664 [ELF] Add test cases for range extension thunks (no linkerscripts) https://reviews.llvm.org/D31665 [ELF] Add test cases for range extension thunks using linkerscripts https://reviews.llvm.org/D31666 Peter
Rafael EspĂndola via llvm-dev
2017-Apr-05 23:14 UTC
[llvm-dev] [LLVM-DEV][LLD] RFC Range Thunks Implementation review for ARM and Mips
> Proposed implementation for range extension thunks > At a high-level we need to solve the following problems: > - Assign addresses more than once > - Maintain state between successive calls of createThunks() > - Synchronization of the linker script and the OutputSection after adding thunksThis last past seems to be the messier. The issue is not with the patch, is with the existing infrastructure that uses a completely different representation for linker scripts and non linker scripts. What I think is needed is for the writer to create a dummy "script" and use what is now LinkerScript::assignAddresses. That "script" would * Contain only OutputSectionCommand. * All string manipulations would have been moved before assignAddress. * All the orphan handling would have been made explicit before assignAddress. * Each OutputSectionCommand would contain just a InputSectionDescription. With this the thunk creation should be able to add thunk to a single location. Cheers, Rafael
Rui Ueyama via llvm-dev
2017-Apr-05 23:24 UTC
[llvm-dev] [LLVM-DEV][LLD] RFC Range Thunks Implementation review for ARM and Mips
Are you suggesting other linker jobs such as creating _end symbols to the linker script? The linker script support was implemented after we wrote the current Writer class, so it is somewhat "plugged in" to the Writer. It might not be the best design, and not many other options have been explored. So there might be room to improve code by moving work loads from the Writer to the LinkerScript. But we need to careful not to hurt performance by doing that. On Wed, Apr 5, 2017 at 4:14 PM, Rafael EspĂndola via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > Proposed implementation for range extension thunks > > At a high-level we need to solve the following problems: > > - Assign addresses more than once > > - Maintain state between successive calls of createThunks() > > - Synchronization of the linker script and the OutputSection after > adding thunks > > This last past seems to be the messier. The issue is not with the > patch, is with the existing infrastructure that uses a completely > different representation for linker scripts and non linker scripts. > > What I think is needed is for the writer to create a dummy "script" > and use what is now LinkerScript::assignAddresses. That "script" would > > * Contain only OutputSectionCommand. > * All string manipulations would have been moved before assignAddress. > * All the orphan handling would have been made explicit before > assignAddress. > * Each OutputSectionCommand would contain just a InputSectionDescription. > > With this the thunk creation should be able to add thunk to a single > location. > > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170405/9a9ccad9/attachment.html>
Seemingly Similar Threads
- [LLD] RFC Range Thunks Implementation review for ARM and Mips
- [LLD] RFC Range Thunks Implementation review for ARM and Mips
- RFC: LLD range extension thunks
- RFC: LLD range extension thunks
- LLD: creating linker-generated sections as input sections instead of output sections