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

via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 23 06:13:02 PDT 2025


kkent030315 wrote:

> > I guess the primary question that still stands open is how to enable `IMAGE_GUARD_PROTECT_DELAYLOAD_IAT|IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION` with MS link.exe?
> 
> > It is recommended that protected delay load be enabled by default if CFG is enabled. Images that run on older operating system versions and that use the operating system’s native delay load support, as noted, may use the delay load IAT in its own section support for backwards compatibility.
> > The option to place the delay load IAT in its own section may not be required if you do not care about running an image on operating systems that predate CFG support, but tools should make that decision based on the minimum operating system support that an image needs.
> 
> To me, that means `IMAGE_GUARD_PROTECT_DELAYLOAD_IAT` _should_ be enabled if using delayload when CFGuard is enabled, and `IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION` _may_ be enabled if it's somehow indicated to the linker that older minimum operating system support is needed (one of the version options like subsystem version?)

Unless I misunderstanding something, I do not know a single case where `IMAGE_GUARD_PROTECT_DELAYLOAD_IAT` is enabled without `IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION`. I haven't seen any such flag (including hidden ones) to only enable the `IMAGE_GUARD_PROTECT_DELAYLOAD_IAT`. Given that, I can almost confidently say that those two are mutually dependent. You are correct.

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


More information about the llvm-commits mailing list