Initial speedup for testing #56
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Features added: - nanoMIPS relocation resolving - nanoMIPS eflags calculation - .nanoMIPS.abiflags section creation - nanoMIPS _gp symbol setup - special .eh_frame handling in maybeReportUndefined - R_NANOMIPS_PCHI20 renamed to R_NANOMIPS_PC_HI20
Added nanoMIPS specific linker relaxations/expansions: - Transformations are conducted through a driver class NanoMipsTransformController. It scans through relocs of executable input sections and performs relaxations/expansions if possible or necessary - New nanoMIPS specific options used in transformations added to lld - New TableGen backend (NanoMipsTransformationPropertyEmitter.cpp) for emitting properties of instructions and relocations, transformation templates used in linker transformations
Changed parsing of the linker script, as some nanoMIPS linker scripts require different set of rules for parsing: - Dot operator can be used as section address expression, and its value should be determined by the latest value of dot, not the current position in the memory region - Alignment for output section is not ignored for nanoMIPS if output section has got address expression - SHT_NOBITS sections don't occupy load addresses - OVERLAY sections can have a load region and memory region and assignment or byte commands in them. This way of parsing is enabled if the option --nanomips-custom-linker-script-type is set, which is off by default.
Changed the way .eh_frame parsing is done for nanoMIPS, as they may contain relocations referring to the size of the CIEs/FDEs. lld reads .eh_frame sections using these sizes so it is necessary that the size value is available at the time of .eh_frame section parsing. It seems like integrated assembler for nanoMIPS is not resolving this relocation at assembly time, but the gnu's assembler for nanoMIPS is resolving it.
Linker relaxation may change relocations (offsets and types). However, when --emit-relocs is used, relocations are simply copied from the input section causing a mismatch with the corresponding (relaxed) code section. This patch fixes this as follows: for non-relocatable RISC-V binaries, `InputSection::copyRelocations` reads relocations from the relocated section's `relocations` array (since this gets updated by the relaxation code). For all other cases, relocations are read from the input section directly as before. In order to reuse as much code as possible, and to keep the diff small, the original `InputSection::copyRelocations` is changed to accept the relocations as a range of `Relocation` objects. This means that, in the general case when reading from the input section, raw relocations need to be converted to `Relocation`s first, which introduces quite a bit of boiler plate. It also means there's a slight code size increase due to the extra instantiations of `copyRelocations` (for both range types). Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D159082
Similar to RISC-V relaxations, nanoMIPS transformations change relocations and they need to be updated before writing them down to output. One difference is that nanoMIPS can add new relocations, not just change them like RISC-V, so during linker transformations size of reloc sections need to be updated if --emit-relocs option is on.
eh_frame start and end symbols need to be defined if there is an eh_frame section. These symbols are needed by libunwind when used without libgcc.
In some linker scripts intended to be used for nanoMIPS builds, there are OUTPUT_FORMAT directives specifying elf32-tradlittlemips or elf32-tradbigmips as output formats. These bfd names result in lld choosing MIPS to be the target machine instead of nanoMIPS. This patch checks if that is the case and changes the machine to be nanoMIPS.
The STARTUP linker script directive works similar to the INPUT directive with one file specified, but it also puts the specified file as the first file to be parsed, similar to putting an object file to be the first parameter on the command line. Errors are emitted if two STARTUP directives were found (there can't be two or more first files) and if archive files are passed as the argument (not yet supported).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.