The command prints out list of functions that were not entered.
Details
Diff Detail
Event Timeline
First bunch of comments from Friday. Will add more later.
tools/sancov/sancov.cc | ||
---|---|---|
63 | LLVM tools use flags (with a notable exception of llvm-dwarfdump) with a dash instead of an underscore. | |
95–106 | Ditto, exit(1) | |
95–106 | Why not exit(1)? LLVM tools use 1 as the exit code in case of an error: ag "exit[(]1[)]" tools | wc -l There's 3 python scripts which violate that, but otherwise the rule is followed pretty much everywhere. | |
442–453 | Please fix the comment: "Print list of not covered functions". | |
444 | Per LLVM style guide: http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
Please, change everywhere (except main) |
tools/sancov/sancov.cc | ||
---|---|---|
344 | What if some file names are in /usr/include? This could happen if some of the functions are inlined from a system header. |
tools/sancov/sancov.cc | ||
---|---|---|
157 | FailIfError, as implemented right now, drops the context in which it occurred. I would expect something like: Error: The end of the file was unexpectedly encountered (4) Please, add an additional string param (like Message) and print it into stderr. In this case the invocation will be like FailIfError("symbolizeInlinedCode: " + ClBinaryName, InliningInfo); and the error message will suddenly become much more useful: Error: symbolizeInlinedCode: lala.o: The end of the file was unexpectedly encountered (4) Note: feel free to improve the actual error message format. The point is to have all the needed data points in the error message. Otherwise, we'll waste our own time later. |
lib/Object/ObjectFile.cpp | ||
---|---|---|
118 | I'd probably prefer if this function returned a Target * to reflect the fact that it isn't really supposed to (nor can it) return an accurate triple but rather something that can be used to summon appropriate bits of MC etc. |
tools/sancov/sancov.cc | ||
---|---|---|
157 | You may also consider to have a macro instead of a function, as it would allow to preserve the code of line. See for example: https://github.com/llvm-mirror/llvm/blob/358918e8dd375e41b4f51e7570a57e123b2951c6/unittests/Support/Path.cpp#L31 The macro in the example is gtest-specific, but it still gives an idea. | |
227 | Why is lookupTarget error critical, while an error in createMCSubtargetInfo is not? | |
249 | Please, remove this empty line. There's no empty line in the similar places above. | |
262 | Could createMCInstrAnalysis fail? If yes, please, add error handling as you did above. | |
267 | A comment why do we skip virtual .text sections is appreated. | |
275 | The more I think, the more it looks to me that an assert or CHECK should be used here. The problem is that asserts are disabled in some environments, and it would be unwise to proceed here. | |
295 | Please, add a better TODO description (if you wish to address some issue here later) | |
296 | A comment about the way you compute this address is appreciated. | |
347 | What happens if you only have a single file? I have a feeling that the file name will be printed as an empty string. |
Mostly fine, several nits below (in addition to Ivan's comments).
I don't quite agree on the change to LLVMObject, that method looks somewhat weird to me. We can probably discuss that separately: for now you seem to only support x86_64-linux anyway.
lib/Object/ObjectFile.cpp | ||
---|---|---|
118 | Agree: you can't rely deduce triple from object file. At the very least, you should reflect that you're guessing the triple in method name. | |
tools/sancov/sancov.cc | ||
102 | nit: please use "static" keyword consistently: it's not really needed for functions, as they are enclosed in anonymous namespace, but if you're willing to keep it - keep it everywhere. | |
136 | Nit: LLVM tends to use RHS variant (as it's an abbreviation). $ grep -rnH "RHS" lib/* | wc -l | |
210 | llvm_unreachable() | |
352 | TBH I don't understand the rationale behind stripping (calculated) common prefix. I can construct weird examples, e.g. imagine I have built my executable from /tmp/a.cc with function foo() and /tmp2/a.cc with function foo(). Suppose I suspect that when I ran my executable only one was executed. I call llvm-cov my.exe and see a.cc:1 foo() Well, thanks :) | |
358 | Just FYI: file names may contain colons, as well as spaces. It's probably not a big deal, but just note that the output of llvm-cov might be not machine-readable. | |
411 | return llvm::make_unique<CoverageData>(std::move(Addrs)); | |
439 | Just *Addrs | |
493 | Add llvm_unreachable() at the end? |
lib/Object/ObjectFile.cpp | ||
---|---|---|
118 | Actually it seems that since the MC constructors use the target triple string we should return a triple string here at least for now. |
ptal
lib/Object/ObjectFile.cpp | ||
---|---|---|
118 | Sorry, can't do. Triple name is used to obtain various pieces of MC. | |
tools/sancov/sancov.cc | ||
157 | This doesn't seem to be the way things are done in llvm tools. I'd keep it as is if you don't mind. | |
267 | I have no idea. This is how it is in objdump. Do you know why? | |
347 | It won't see the if (FileName.size() > FilePrefix.size()) below. |
lib/Object/ObjectFile.cpp | ||
---|---|---|
118 | Yeah, let's copy the code, and remove the cases we don't really support yet (MachO/COFF). | |
tools/sancov/sancov.cc | ||
493 | See http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations |
tools/sancov/sancov.cc | ||
---|---|---|
157 | Can you please give me examples of that in llvm tools? | |
267 | No I don't. Please, at least, add a comment that the code was stolen from objdump. Please, give a more precise location, so that it would be possible to lookup later for a reader that is not you or me. | |
365 | I also think that it's not the right feature. If we want strip prefixes, that should be a flag that specifies the prefix, not auto-magic. |
I removed common path functionality and implemented strip_path_prefix flag instead. PTAL.
Please, mark the comments which are addressed as done. It will make it
easier to follow the review.
I'd probably prefer if this function returned a Target * to reflect the fact that it isn't really supposed to (nor can it) return an accurate triple but rather something that can be used to summon appropriate bits of MC etc.