This is an archive of the discontinued LLVM Phabricator instance.

[llvm][CodeGen] Skip WinCFGuard on non-Windows targets
AbandonedPublic

Authored by alvinhochun on Aug 26 2022, 2:44 AM.

Details

Summary

This fixes a crash when passing -cfguard to the clang frontend while not
targeting Windows. Control Flow Guard is only supported on Windows.

Diff Detail

Event Timeline

alvinhochun created this revision.Aug 26 2022, 2:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2022, 2:44 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
alvinhochun requested review of this revision.Aug 26 2022, 2:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2022, 2:44 AM
aaron.ballman added inline comments.
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
588–589

CodeGen is not my area of strength, so this might be a silly question, but wouldn't it be better to prevent cfguard from being added to the module flags in the first place?

rnk added inline comments.Aug 26 2022, 11:24 AM
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
588–589

I believe cfguard is an Xclang flag, so this is already protected in some ways. We generally add logic to the driver to defend against misusage, but the cc1 interface is relatively raw and unchecked.

So, I guess in conclusion, I think we probably have enough checking, and it makes sense for us to add this check to guard against crashing (assuming that's what happens later).

nit: make the condition isOSBinFormatCOFF just to guard against some obscure Windows ELF configurations.

aaron.ballman added inline comments.Aug 26 2022, 11:41 AM
llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
588–589

SGTM, though I don't really want us to go overboard protecting against -Xclang misuse (when someone does that and gets a crash, I don't lose a whole lot of sleep because -Xclang voids all warranties).

Emitting IR to support CFGuard but then ignoring it in hacky ways in the backend just seems wrong. If there's never going to be an effort to support it outside of Windows, then it shouldn't go into the IR at all; if there is, then all parts of the systems should do their best, with an understanding that it may not work because it's experimental at best.

There are three reasonable alternatives here, and we should pick one of them:

  1. CFGuard on non-Windows is an unwanted feature, and we should handle frontend requests for it by emitting an error.
  2. CFGuard on non-Windows is an unwanted feature, and we should handle frontend requests for it by ignoring them.
  3. CFGuard on non-Windows is an unsupported, experimental feature that users shouldn't request unless they're willing to accept that things will break because it's not complete yet (and may not be for the indefinite future).
alvinhochun abandoned this revision.Sep 23 2022, 2:28 AM

I do agree that misusing cc1 flags voids all warranties so I don't want to spend too much effort in adding checks. Looking at clang/lib/CodeGen/CodeGenModule.cpp there aren't any existing checks guarding other Windows-specific flags either, so I guess I will just leave it as is.