[llvm-bugs] [Bug 44208] New: clang-cl with coverage saves gcno files in root, rather than next to obj file

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Dec 3 00:55:42 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=44208

            Bug ID: 44208
           Summary: clang-cl with coverage saves gcno files in root,
                    rather than next to obj file
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jeffrey.vandeglind at nobelbiocare.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

While trying to generate code coverage reports for our project, I had an issue
where multiple files with the same name caused issues regarding the writing of
gcda files. Searching online, everything pointed towards gcno files having to
be stored next to the obj files, but for me they were always in the root
folder.

After self-compiling the release_90 branch and inserting some debug prints I
noticed that my generated ninja files didn't contain a -o option. After adding
it, I noticed -o is interpreted as /o, and thus the line that checks for OPT_o
fails, since it is OPT__SLASH_o. It then simply falls back to taking PWD and
source file and generate a path in root.

I then noticed that the flag that clang-cl should actually be looking for is
OPT__SLASH_Fo
(https://docs.microsoft.com/en-us/cpp/build/reference/fo-object-file-name?view=vs-2019),
so I updated to code (Clang.cpp - addPGOAndCoverageFlags() ~ line 888) to look
like this:

    CmdArgs.push_back("-coverage-notes-file");
    SmallString<128> OutputFilename;
    Arg *FinalOutput = C.getArgs().getLastArg(options::OPT_o);
    if (!FinalOutput)
        FinalOutput = C.getArgs().getLastArg(options::OPT__SLASH_Fo);
    if (FinalOutput)
        OutputFilename = FinalOutput->getValue();

This fixes the position of the gcno files. However, I do not know if I am
overseeing some other issues that might pop up due to this change.

My setup is:
Self compiled LLVM + Clang release_90
Microsoft Visual Studio 2019 x64 environment
CMake 3.15 + Ninja 1.9.0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191203/01a76d6d/attachment-0001.html>


More information about the llvm-bugs mailing list