If profile data is malformed for any kind of reason, we generate
an error that only reports "malformed instrumentation profile data"
without any further information. This patch extends InstrProfError
class to receive an optional error message argument, so that we can
do better error reporting.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I think this is a great change but the messages could be improved. Saying that value is corrupted in every case doesn't really say much plus it's not clear if the value has really been corrupted, there are other ways in which the data can become invalid (like using incompatible runtime version or compiler error). Rather I'd try to explain what's the issue in concise terms. I left a few suggestions, hopefully you'll get the point.
llvm/include/llvm/ProfileData/InstrProf.h | ||
---|---|---|
325 | I'd call this just getMessage which is what StringError does as well. | |
342 | I'd call this just Msg which is what StringError does as well. | |
llvm/lib/ProfileData/Coverage/CoverageMappingReader.cpp | ||
572 | I'd omit the CovMapFuncRecordReader which may not be useful for most users. | |
llvm/lib/ProfileData/InstrProf.cpp | ||
79 | I'd use raw_string_ostream to assemble the message. This would like like this: std::string Msg; raw_string_ostream OS(Msg); switch (Err) { case instrprof_error::success: OS << "success"; break; ... } ... return OS.str(); | |
152 | Some of the error messages above already include details in parenthesis and having multiple parenthesis might look awkward so I'd use : as a separator instead. | |
914 | These are not full sentences so they shouldn't be capitalized, the same for all the other messages below.. I'd also consider moving the Integrity check failure at the end in parenthesis as an additional qualifier. Regarding this particular error message, I think you can make it even more specific (corrupted is too generic) by saying something like "number of value profile kinds is invalid". | |
919 | Rather than corrupted, I'd say something like "total size is not congruent modulo quardword size". | |
925 | I'd use "value kind is invalid" not corrupted. | |
929 | Maybe something like "address of the next value profile record is greater than the total size". |
- Addressed Petr's comments
- Add two malformed profile tests
- Change error messages in existing malformed profile tests
I find it cleaner just to expand known malformed errors into its own error category. WIth that the change can also be minimized.
llvm/lib/ProfileData/InstrProfReader.cpp | ||
---|---|---|
462 | Actually here it could be either the counter offset that's out of bounds, or the number of counters that's out of bounds, so perhaps we should split this into two separate checks. |
@davidxl, adding an optional diagnostic error message to InstrProfError gives us the flexibility to do that not only for malformed profiles, but for other kind of profile errors.
I only added for malformed profiles because it was our current use case. But, we can later extend it for other kind of profile issues.
This is why I would prefer not to have another error category for malformed profiles.
Please let me know what you think about that.
I missed the latest patchset. I have a few more comments, feel free to address those in follow up changes.
llvm/lib/ProfileData/InstrProf.cpp | ||
---|---|---|
153 | I'd omit the extra quotes, that's more consistent with the way Clang and other tools report errors | |
llvm/lib/ProfileData/InstrProfReader.cpp | ||
465 | In error messages, we usually prefer spelling things out fully, so this should be counter offset X is negative, I'd omit the parenthesis. | |
469–471 | Here I'd say counter offset X is greater that the maximum number of counters Y. | |
476–480 | Similarly here I'd say just number of counters X is greater than the maximum number of counters Y where X would be a sum of CounterOffset and NumCounters, no need to report those separately since you already check the offset above. |
@gulfem This is failing on some buildbots: https://lab.llvm.org/buildbot/#/builders/109/builds/25948 please can you take a look?
The test seems to require zlib which means either that dependency needs to be removed, or a "REQUIRES: zlib" needs to be added.
@RKSimon and @dyung,
Thanks for reporting, and I have already pushed a change that removed the dependency to zlib on those tests:
https://github.com/llvm/llvm-project/commit/126e7611c70ca41782aa851c2bec132607eb8127
After the fix, bot turned green.
https://lab.llvm.org/buildbot/#/builders/109/builds/25973
@phosek, I also addressed your comments in:
https://github.com/llvm/llvm-project/commit/126e7611c70ca41782aa851c2bec132607eb8127
I'd call this just getMessage which is what StringError does as well.