[lld] [LLD] [MinGW] Implement --dependent-load-flag option (PR #113814)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> IIUC static libraries won't even contain that symbol, and in this case it should be provided only by mingw-w64.
> 
> I think this example backs up my point:
> 
> ```
> $ rg "_load_config_used" /clang64/lib -la -g '*.a'
> H:/msys64/clang64/lib\liblldCOFF.a
> H:/msys64/clang64/lib\libmingwex.a
> 
> $ nm /clang64/lib/libmingwex.a | rg _load_config_used
> 00000000 R _load_config_used
> 00000138 r _load_config_used__end
> ```

I don't see how that contradicts what I'm saying :-) As long as `libmingwex.a` is involved in the link, LLD will pull the `_load_config_used` symbol from there.

Case in point:
```
$ x86_64-w64-mingw32-clang test/hello.c -o hello.exe
$ llvm-readobj --coff-load-config hello.exe

File: hello.exe
Format: COFF-x86-64
Arch: x86_64
AddressSize: 64bit
LoadConfig [
  Size: 0x138
  TimeDateStamp: 1970-01-01 00:00:00 (0x0)
  MajorVersion: 0x0
  MinorVersion: 0x0
  GlobalFlagsClear: 0x0
  GlobalFlagsSet: 0x0
  CriticalSectionDefaultTimeout: 0x0
  DeCommitFreeBlockThreshold: 0x0
  DeCommitTotalFreeThreshold: 0x0
  LockPrefixTable: 0x0
  MaximumAllocationSize: 0x0
  VirtualMemoryThreshold: 0x0
  ProcessHeapFlags: 0x0
  ProcessAffinityMask: 0x0
  CSDVersion: 0x0
  DependentLoadFlags: 0x0
  EditList: 0x0
  SecurityCookie: 0x0
  SEHandlerTable: 0x0
  SEHandlerCount: 0
  GuardCFCheckFunction: 0x14000AAD0
  GuardCFCheckDispatch: 0x14000AAD8
  GuardCFFunctionTable: 0x0
  GuardCFFunctionCount: 0
  GuardFlags [ (0x100)
    CF_INSTRUMENTED (0x100)
  ]
  GuardAddressTakenIatEntryTable: 0x0
  GuardAddressTakenIatEntryCount: 0
  GuardLongJumpTargetTable: 0x0
  GuardLongJumpTargetCount: 0
  DynamicValueRelocTable: 0x0
  CHPEMetadataPointer: 0x0
  GuardRFFailureRoutine: 0x0
  GuardRFFailureRoutineFunctionPointer: 0x0
  DynamicValueRelocTableOffset: 0x0
  DynamicValueRelocTableSection: 0
  GuardRFVerifyStackPointerFunctionPointer: 0x0
  HotPatchTableOffset: 0x0
  EnclaveConfigurationPointer: 0x0
  VolatileMetadataPointer: 0x0
  GuardEHContinuationTable: 0x0
  GuardEHContinuationCount: 0
]
```
(This tested with llvm-mingw, but I presume it would behave the same in msys2.)

> For mingw-w64, at least for now `_load_config_used` is only compiled when CFG is enabled for mingw-w64-crt itself, because CFG had been the only feature that required it: https://github.com/mingw-w64/mingw-w64/blob/fab7cfe34e5388c920230d0237e3663804d91458/mingw-w64-crt/Makefile.am#L967-L971 One of the benefits is to allow LLD to emit a warning if the user tries to enable CFG with a mingw-w64-crt that was not compiled with CFG. ([365d0a5](https://github.com/llvm/llvm-project/commit/365d0a5cd867cdf414b70c9f4fd5122146287b01))

Ah, right, I forgot about that detail. I presume that this is what @mati865 was referring to?

> But if there is a new reason to require the load config directory, then we need to change how `_load_config_used` is defined in mingw-w64-crt. What _probably_ should happen is that we move `mingw_cfguard_loadcfg.S` out of `crguard` to always compile it, and change its contents to only define the CFG-related symbols when mingw-w64-crt is being built with CFG enabled. This way the CFG stuff won't interfere with non-CFG builds and the LLD warnings can still work.

Yep, this sounds reasonable to me. IIRC ARM64EC stuff also requires the load config.

> It may also be beneficial to add a check in LLD to emit a warning if `--dependent-load-flag` is set but `_load_config_used` is not available, especially if this feature affects security.

That sounds like a very good addition here!

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