Patch D31939 is not complete (does not support cross compiling). This patch solves the problem. The compiler needs to check the target triple to decide section naming scheme.
Details
- Reviewers
vsk - Commits
- rGf0e879dffd1e: [Profile] PE binary coverage bug fix
rG57dea2d35917: [Profile] PE binary coverage bug fix
rG3bb31c8c4906: [Profile] PE binary coverage bug fix
rCRT300278: [Profile] PE binary coverage bug fix
rC300279: [Profile] PE binary coverage bug fix
rL300278: [Profile] PE binary coverage bug fix
rL300279: [Profile] PE binary coverage bug fix
rL300277: [Profile] PE binary coverage bug fix
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/ProfileData/Coverage/CoverageMappingReader.cpp | ||
---|---|---|
651 ↗ | (On Diff #95141) | It doesn't look like getInstrProfNameSectionName() returns the correct section name for COFF files here. With the exception of the ELF-specific change in TargetLoweringObjectFileImpl.cpp, this comment applies everywhere else in this patch where a module is not passed in to the get*SectionName helper. Do you think we need a mandatory way to tell the get*SectionName functions which file format we're working with? |
lib/ProfileData/InstrProf.cpp | ||
257 ↗ | (On Diff #95141) | These get*SectionName functions are getting a bit unwieldy. Wdyt of consolidating them? There are two inputs: ObjectFileKind ({MachO, COFF, Other}), and ProfInfoKind ({Counters, Names, Data, Values, Vnodes, Coverage}). We just need one function: StringRef getInstrProfSectionName(ObjectFileKind, ProfInfoKind). |
lib/ProfileData/Coverage/CoverageMappingReader.cpp | ||
---|---|---|
651 ↗ | (On Diff #95141) | You are right here. However this patch is about cross compilation support, not about host tool support for other platforms. I can add a comment and TODO here that the binary format is assumed to be the native format on the host platform. |
lib/ProfileData/InstrProf.cpp | ||
257 ↗ | (On Diff #95141) | True. I will see if a refactoring is doable. |
LGTM with a few minor changes.
lib/ProfileData/InstrProf.cpp | ||
---|---|---|
172 ↗ | (On Diff #95234) | We can simplify this function with an early return: if (!M) return InstrProfSectName[Kind];. One less null check. |
lib/Transforms/Instrumentation/ThreadSanitizer.cpp | ||
284 ↗ | (On Diff #95234) | nit, clang-format |
tools/llvm-cov/TestingSupport.cpp | ||
54 ↗ | (On Diff #95234) | Could you replicate your TODO comment here? ( 'to support Win->ELF cross compilation with coverage properly'...) |
Fixed in r300289.
llvm/trunk/include/llvm/ProfileData/InstrProf.h | ||
---|---|---|
94 | It causes requiring LLVMProfileData for its users, for example, LLVMCodeGen. |
llvm/trunk/include/llvm/ProfileData/InstrProfData.inc | ||
---|---|---|
666 | This ifdef breaks cross compiling. In particular, llvm/test/Instrumentation/InstrProfiling/X86/alloc.ll is failing on Windows since this change. LLVM should choose the section name at runtime based on the target triple, not the host defines. |
llvm/trunk/include/llvm/ProfileData/InstrProfData.inc | ||
---|---|---|
666 | Oops, I think I spoke too soon. I don't think I understand why the test is failing yet. |
llvm/trunk/include/llvm/ProfileData/InstrProfData.inc | ||
---|---|---|
666 | Yeah, it's not the ifdef (sorry), it's the TODOs in llvm-cov that highlight all the points where cross-running llvm-cov on a binary with a different object format from the host will fail. I wrote https://reviews.llvm.org/D32090 to try to address that, but I'm open to other ideas. |
It causes requiring LLVMProfileData for its users, for example, LLVMCodeGen.