We've had a longstanding incompatibility with MSVC where we don't emit a couple of CodeView records that normally go in each file. This patch aims to address the first of these records - the S_OBJNAME symbol. This symbol is very simple. It just contains the full path to the object file that the debug info is being emitted to.
When building from clang, the approach taken here is to use the target file name, as decided by the CompilerInstance::createDefaultOutputFile. It is then passed down to the backend through MCTargetOptions, to make it available to CodeViewDebug. The same approach is taken when using llc or LTO/ThinLTO (through LLD or llvm-lto2). When emitting to stdout (path is '-'), we emit the S_OBJNAME record with an empty name.
The objective of this patch is to support live code patching tools like Recode or Live++. They are different from Microsoft Edit & Continue, which we don't plan to support. Several changes are needed in LLVM to support these tools:
Let's bikeshed the name a bit. This thing is the -o//Fo value, plus some processing. It can be symbolic, as in -. It could be the name of a bitcode file with -flto. It could be the name of an assembly file if you do clang -S --target=x86_64-windows-msvc -g t.cpp -o t.s. It could be the name of an ELF file if you try hard. I think in any of these cases where the user directly emits something that isn't a COFF object, it's OK to use that name for the S_OBJNAME record.
What it is, is the name of the compiler's output file, as we would like it to appear in debug info. With that in mind, here are some ideas:
I think I like ObjectFilenameForDebug best. DebugObjectFilename seems like a no-go, since that sounds like the dwo file name.
This brings me to the case of -save-temps / /Fa. In these cases, the compile action is broken into pieces, and the assembler is invoked in a follow-up process. Does that mean the driver needs to pass an extra flag along to the -cc1 action? That would be a bummer.