[PATCH] D44501: COFF: Move assignment of section offsets to assignAddresses(). NFCI.

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

In https://reviews.llvm.org/D44501#1201988, @mstorsjo wrote:

> In https://reviews.llvm.org/D44501#1200976, @pcc wrote:
>
> > In https://reviews.llvm.org/D44501#1200972, @smeenai wrote:
> >
> > > In https://reviews.llvm.org/D44501#1200324, @mstorsjo wrote:
> > >
> > > > > This makes the design a little more similar to the ELF linker and should allow for features such as ARM range extension thunks to be implemented more easily.
> > > >
> > > > @pcc - I found you mentioned this as part of this change; do you have any concrete plan on how to add ARM range extension thunks? I'm pondering giving that a try, but if you have ideas about how/where to start, that'd get me started quicker.
> > >
> > >
> > > Have you looked at their design in the ELF port? CC @peter.smith, who added that support.
> >
> >
> > Yes, I was broadly imagining that it would work in a similar way to the ELF port.
>
>
> I tried to look briefly at the commit that added the range extension thunks for ELF, but I guess I should look at more of it than that commit, since it seemed to rely on some generic thunking support that existed before. Or perhaps I should just have another look.


I'm not familiar with the COFF codebase so I can't comment on specifics of how a Thunk implementation would work. There is quite a large possible design space and there are some things that you may not need to support in COFF. For example I'm guessing you won't need to support Mips, and the placement restrictions of LA25 Thunks or Arm/Thumb interworking.

In general for range extension thunks the biggest problem is that you need to know the range between caller and callee, but inserting Thunks will affect the ranges. You can do a simple Thunk implementation without precise addresses or ranges by lowering the branch ranges by some guess of the number of Thunks you'll need. For ELF with arbitrary linker scripts this approach can fail enough times with corner cases that it is worth assigning addresses and iterating till no more Thunks are needed. If COFF doesn't have linker scripts and your placement strategy is conservative enough you may be able to get away with a single pass without needing precise address information. Personally I'd recommend using precise addresses as it can be difficult to debug when the imprecise version doesn't work.

The largest bit of the design space is where to place the Thunks. In ELF we went for a pool of Thunks at roughly branch range intervals. With some special case code for Thunks that can't be placed in any of these pools (the Thumb2 conditional branch has a lower range than the unconditional branches). This is a reasonable balance of implementation complexity and optimisation of placement for reuse. A simpler method would be to place each generated Thunk immediately before or after the caller's Section.

Anyway, good luck.


Repository:
  rL LLVM

https://reviews.llvm.org/D44501