[PATCH] D70606: LLD: CET shadow stack support on Windows

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 25 23:02:29 PST 2019


mstorsjo added inline comments.


================
Comment at: lld/MinGW/Options.td:105
 def: F<"nxcompat">;
+def: F<"cetcompat">;
 def: F<"pic-executable">;
----------------
penzn wrote:
> mstorsjo wrote:
> > penzn wrote:
> > > mstorsjo wrote:
> > > > FWIW, if you want the option to actually have any effect when passed to the mingw driver, you need a couple lines in MinGW/Driver.cpp (and a corresponding test in test/MinGW/driver.test).
> > > Good point, thank you. That is intentional - I noticed that other MSVC security flags have no effect in MinGW driver.
> > > 
> > > There is a patch for GNU-compatible linker on Linux, [[ https://reviews.llvm.org/D59780 | D59780 ]], though I am not sure if we can simply wire those options to COFF implementation introduced here. The goal of this patch is to support the VS-compatible flag.
> > > 
> > > I might be wrong with my assumptions on MinGW driver, any clarification would be greatly appreciated.
> > Well, some of them, like nxcompat, are enabled by default within lld, and I'm not sure there's any GNU linker option to disable it, so therefore we don't actually act upon that option, while other flags like dynamicbase do exist and are forwarded.
> > 
> > As there's no predecent for these options being used in the wild with GNU ld for mingw so far, you could just omit it from this file if you aren't planning on hooking it up, as it won't be necessary for compatibility with existing projects built for mingw.
> > 
> > But I presume it could make sense to enable this flag in mingw configurations as well (would it?), and in that case, hooking it up with the same option name as for the ELF frontend, forwarding it to the link/COFF style flag name would be most welcome.
> GNU would have its own CET flags, there is an effort to port them to LLD in [[ https://reviews.llvm.org/D59780 | D59780 ]]. I can remove the flag from MinGW to avoid confusion, though I don't feel strongly either way. What do you think?
Yes, I'd prefer to not add any code for the MinGW driver until it does something meaningful in this case.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70606/new/

https://reviews.llvm.org/D70606





More information about the llvm-commits mailing list