[PATCH] D77694: [WIP][RISCV][ELF] Linker relaxation support

Fri Apr 10 08:27:36 PDT 2020

psmith added a comment.

In D77694#1969073 <https://reviews.llvm.org/D77694#1969073>, @psmith wrote:

> Will have to have a think about this in more detail over the Easter Weekend.
>
> I do have some experience with relocations being scanned multiple times. As George mentions, performance, particularly for very large programs with millions of relocations is a concern, especially for a linker that is most attractive to its user base for high performance. The performance impact can be mitigated by only doing what you need when scanning the relocations early. For example in a debug build the number of relocations vastly outweighs the number of non-debug relocations yet we are unlikely to need to scan them early. The downside of this approach is that we have a large non-local dependency between the relocation scans which can make the implementation fragile. For example it is easy to forget that something needs to be done in scan pass 1, only to see some problem come up with scan pass 2 that depended on it. Overall we'll only know by measuring on several large programs.

Apologies not got a lot more to add at the moment.

> the mutableData/makeMutableDataCopy is a bit of a gross hack that could potentially go wrong if consumers of data hang on to now-stale pointers,

If we were single threaded I think the risk of holding on to stale pointers is low and probably could be managed with warnings in comments and code-review. I think our most likely cause of problem would be during multithreaded parts of the program. if Thread 1 gets an address to the read-only data, just after but before Thread 1 has finished, Thread 2 makes a mutableCopy, with possibilities of inconsistencies. I've not got any great suggestions on how to fix this. One way might be to make the interface a bit more explicit, for example any section containing relaxations, even if they aren't relaxed get copied.

> The current place is wrong for a thunk target (e.g. AArch64). I did not write code because I am still unsure how to properly do linker relaxations.

One thing that concerns me is convergence. In finalizeAddressDependentContent() we have had to be careful to avoid the edge case where simultaneously adding and subtracting content end up with oscillations and non-convergence. I think that we've managed that so by locking the size of some sections like the Thumb relocations. My guess is that architectures will choose Thunks or Relaxations but can't easily support both at the same time, with Thunks adding content and Relaxations shrinking it. I do hope that RISCV doesn't end up having to write the equivalent of the Erratum patches, I guess there would be an implementation that could use relaxations.

> We need to move scanRelocations() as late as possible and move some passes (including finalizeSynthetic()) into finalizeAddressDependentContent(). These passes need to refactored to work if called more than once.

After investigating https://bugs.llvm.org/show_bug.cgi?id=44824 .ARM.exidx needs this right now as a linker script can have non-monotonically increasing VMA despite having a monotonically increasing sectionIndex. This leads to an incorrect order in the .ARM.exidx table. I'll start work on pr44824 next week.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77694/new/

https://reviews.llvm.org/D77694