using the original file name for compiling preprocessed files ("-main-file-name"?)

Clang Frontend
#1

Hi,

I would like to call clang twice, once to preprocess and second time to compile.
The second time clang is called, I would like to pass in the original file name for it to use as the ModuleID.
I tried to use:
clang -E test.c -o tmp.i
clang -S -x c tmp.i -o test.s -Xclang -main-file-name -Xclang test.c -emit-llvm

However, the ModuleID is ‘tmp.i’ rather than that passed in by ‘-main-file-name’.

Same with:
clang -cc1 -triple x86_64-unknown-linux-gnu -x c tmp.i -o test.s -main-file-name test.c -emit-llvm

I am trying to achieve the same affect as using “-fpreprocessed -dumpbase ” with llvm-gcc.
Here it seems the gcc front end fetches the file name from the first line of the preprocessed file.

Thank you.

Robert

#2

Hi,

I would like to call clang twice, once to preprocess and second time to
compile.
The second time clang is called, I would like to pass in the original file
name for it to use as the ModuleID.
I tried to use:
   clang -E test.c -o tmp.i
   clang -S -x c tmp.i -o test.s -Xclang -main-file-name -Xclang test.c
  -emit-llvm

However, the ModuleID is 'tmp.i' rather than that passed in by
'-main-file-name'.

This seems like a bug to me; -main-file-name should be used as the name of
the input in all respects other than where we find it on disk. Care to put
together a patch to fix this? (I doubt you'll be able to get anyone else to
care much about what ends up in ModuleID, so I think you'll need to do the
work yourself here...)

#3

Hi Richard,

I’ve tried to follow it through from both ends but lost my way.
I’ll have a second go at it and suggest a patch.

thank you

Robert

#4

Hi Richard,

The data route to set the ModuleID is below.
At some stage the code should have used getCompilerInstance().getCodeGenOpts().MainFileName I believe.
However, I am not familiar enough to know who needs the real file name and who needs the original file name.

I tried a patch at FrontendAction::BeginSourceFile(), but not all unit tests passed - not looked into why yet.
A patch later when we create the BackendConsumer() “seems to work” - see below-below.

Robert

lib/Frontend/CompilerInstance.cpp
CompilerInstance::ExecuteAction()
(Input = getFrontendOpts())

lib/Frontend/FrontendAction.cpp
BeginSourceFile(Input)
InFile = Input.getFile();
FrontendAction::CreateWrappedASTConsumer(InFile)

lib/CodeGen/CodeGenAction.cpp
CodeGenAction::CreateASTConsumer(InFile)
OS(Infile)
BackendConsumer(infile) : ASTConsumer

lib/CodeGen/ModuleBuilder.cpp
clang::CreateLLVMCodeGen(ModuleName)
CodeGeneratorImpl(ModuleName)
llvm
llvm::Module(ModuleName)

diff --git a/lib/CodeGen/CodeGenAction.cpp b/lib/CodeGen/CodeGenAction.cpp
index 795b127…d952fbf 100644
— a/lib/CodeGen/CodeGenAction.cpp
+++ b/lib/CodeGen/CodeGenAction.cpp
@@ -543,10 +543,12 @@ ASTConsumer *CodeGenAction::CreateASTConsumer(CompilerInstance &CI,
LinkModuleToUse = ModuleOrErr.get();
}

  • StringRef mainFileName = getCompilerInstance().getCodeGenOpts().MainFileName;
  • if (mainFileName.empty())
  • mainFileName = InFile;
    BEConsumer = new BackendConsumer(BA, CI.getDiagnostics(), CI.getCodeGenOpts(),
    CI.getTargetOpts(), CI.getLangOpts(),
  • CI.getFrontendOpts().ShowTimers, InFile,
  • CI.getFrontendOpts().ShowTimers, mainFileName,
    LinkModuleToUse, OS.release(), *VMContext);
    return BEConsumer;
    }