[lld] [LLD][COFF] Move delay IAT into its own .didat section. (PR #137100)

[Jacek Caban via llvm-commits]

cjacek wrote:

Note that lld-link aims to be compatible with MSVC. The MinGW mode differs in several respects, but even that shouldn't diverge unnecessarily when it can be avoided.

I did some experimentation with MSVC, I feel this PR mixes a few distinct concerns:

1. Marking `.didat` as writable
 This matches MSVC behavior. If I try linking a custom read-only `.didat` section, MSVC issues a warning that the section already exists with different permission flags. I think this part is fine.

2. Skipping merging of `.didat` into `.rdata`
 This doesn't match MSVC. MSVC merges `.didat` into `.rdata`, though there are caveats:
 - The merge happens only if there is at least one delay-loaded module. If not, no merge is performed.
 - While most of `.didat` is merged into `.rdata`, `.didat$5` is instead merged into `.data`. LLD handles this by adding synthetic chunks directly to `.data`, which has the same effect at runtime, though it makes the map file look different.

3. Moving the delay IAT into a separate section
 While MSVC appears to support this, I couldn’t find a way to make it emit such layout in practice. I don’t think we should differ from MSVC by default. It might be interesting to support this as an opt-in feature, but ideally, it should be done in a way that is compatible with MSVC.
 Also, if we go that route, we should update `__guard_flags` accordingly. Otherwise, we’re just increasing section count without gaining any security benefit.

That said, to allow dlltool to create long-form delay-load import libraries, we could just fix (1) and condition merging of `.didat` on actual `-delayload` usage. That is, we’d assume that if someone is using a long-form import library, they aren’t using `-delayload`, so the merge wouldn’t happen.

Side note: While improving GNU dlltool is helpful in the short term, it would be ideal if binutils gained native `-delayload` support. That would make it easier for the MinGW ecosystem to adopt proper delay-loading. The current approach is cumbersome, which is probably why it’s rarely used in practice.

https://github.com/llvm/llvm-project/pull/137100