This is an archive of the discontinued LLVM Phabricator instance.

[ProfileData] Support cross target binary reading for coverage tool
ClosedPublic

Authored by davidxl on Apr 13 2017, 9:10 PM.

Details

Summary

This is a follow up to the patch that added the coverage support for PE binary. This patch also fixes the rest of test failures.

Diff Detail

Repository
rL LLVM

Event Timeline

davidxl created this revision.Apr 13 2017, 9:10 PM
davidxl updated this revision to Diff 95267.Apr 13 2017, 9:12 PM

Remove stale TODO

davidxl updated this revision to Diff 95268.Apr 13 2017, 9:49 PM
vsk edited edge metadata.Apr 13 2017, 10:29 PM

I'm not aware of what the test failures are, but if they are affecting CI I'd prefer to revert everything temporarily.

As it stands this patch looks functionally OK, but I'm concerned about having overloads of the get*SectionName functions that do vs. do not include segment prefixes. I.e it's confusing to me that getInstrProfCoverageSectionName(/*isCoff*/false) and getInstrProfCoverageSectionName(MachOModule) return different results.

Wdyt of removing all of the get*SectionName helpers, and just exposing: getInstrProfSectionName(InstrProfSectKind IPSK, ObjectFileKind OFK, bool AddSegmentPrefix). It will make client code more verbose but very clear / unambiguous.

The failures are only on windows platform. Since the change touches three repos and and there were also incremental fixes applied later, it is better to roll forward than rolling back.

The main client (the compiler) should not need to know the details so a higher level interface taking 'Module' should be better. It is the host tool that need to use the lower level interface. For the later use, there was never a need for segment prefix, so adding the flexibility is not necessary.

vsk added a comment.Apr 14 2017, 8:56 AM

The main client (the compiler) should not need to know the details so a higher level interface taking 'Module' should be better.

I see your point, but taking a 'Module' doesn't seem to be nicer, because it forces us to expose more APIs which are very slightly different from each other. This leaks details because in order to pick the right API, you need to know the low level details (e.g whether or not segment prefixes are needed).

Wdyt of removing all of the get*SectionName helpers, and just exposing: getInstrProfSectionName(InstrProfSectKind IPSK, ObjectFileKind OFK, bool AddSegmentPrefix). It will make client code more verbose but very clear / unambiguous.

It is the host tool that need to use the lower level interface. For the later use, there was never a need for segment prefix, so adding the flexibility is not necessary.

We could set 'bool AddSegmentPrefix = true' by default. This still provides some extra flexibility, but the right option is picked by default, so there should be less confusion.

If you'd prefer to extend the set of get*SectionName() functions, I just ask that the names of the "getXSectionName(bool)" and "getXSectionName(Module *)" functions be made different.

davidxl updated this revision to Diff 95312.Apr 14 2017, 10:00 AM

Changed the new interface name according to review feedback.

vsk accepted this revision.Apr 14 2017, 10:51 AM

Thanks, LGTM. I will send a patch out with the alternate take on the API for your consideration -- it may turn out that this is simpler.

This revision is now accepted and ready to land.Apr 14 2017, 10:51 AM
This revision was automatically updated to reflect the committed changes.