[PATCH] D32330: X86: Don't emit zero-byte functions on Windows

[Hans Wennborg via Phabricator via llvm-commits]

hans added a comment.

In https://reviews.llvm.org/D32330#733021, @MatzeB wrote:

> Sounds like a good story :)
>
> - We have various MachineInstr that do not result in actual code getting created (DEBUG_INFO, Labels, etc.) this wouldn't catch them.
> - There is a very similar situation handled in AsmPrinter.cpp already around line 1049: ``` // If the function is empty and the object file uses .subsections_via_symbols, // then we need to emit *something* to the function body to prevent the // labels from collapsing together.  Just emit a noop. ``` maybe you can do some refactoring there to do the COFF empty function handling as well?


Nice! I'll try that.

In https://reviews.llvm.org/D32330#733026, @mkuper wrote:

> What does MSVC do for this? Is MSVC's behavior predicated on /guard:cf? Is it ok to generate empty functions without /guard:cf? Crash on calling an empty function seems like somewhat non-intuitive behavior.
>  Also, what about thumbv7-windows?


I haven't been able to lure MSVC into emitting a zero-byte function. For example, for

  __declspec(naked) void f() {}

they emit an int3.

We can't put this behind the /guard:cf flag (in fact, clang-cl doesn't even support it right now), because the problem happens when the linker is invoked with /guard:cf, it builds the guard table even if the compiled code isn't instrumented with control-flow checks.

I don't think crashing on calling a zero-byte function is non-intuitive; the function has no ret instruction, so anything could happen. Since Matthias pointed out we already have a function that inserts nops in similar situations, I'm happy to use that instead.

I don't know if CFG is a thing on thumbv7-windows, but if we're doing it in the asm printer now, it's easy to just enable for all windows targets.


https://reviews.llvm.org/D32330