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

via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 21 01:24:43 PST 2024


alvinhochun wrote:

> > > And as high level view of what it does - this sets one value in the `_load_config_used` struct, if such a symbol happens to be found at link time, right?
> > 
> > 
> > Yeah, that's how I understand it. Which means it has an effect only when using Control Flow Guard is enabled.
> 
> Hmm, but isn't `_load_config_used` linked in whenever it is found in any of the static libraries? https://github.com/llvm/llvm-project/blob/main/lld/COFF/Driver.cpp#L2582-L2584
> 
> So with that, `_load_config_used` should mostly always be linked in, and this option should always end up setting the right flags in the load config, or am I missing something? (CC @alvinhochun)

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. (365d0a5cd867cdf414b70c9f4fd5122146287b01)

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.

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.

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


More information about the llvm-commits mailing list