-Adjust the CMake
-Adjust the tool to work on Windows (skip the backslash character from JSON string)
-Adjust the test case to work on Windows
Thu, Sep 12
-Adjust the CMake
This was reverted with the rL371527 due to test failure on Windows platform.
@dstenb Thanks for this! This makes sense.
Wed, Sep 11
An idea: After this got implemented, we can add a new sub-directory inside the debuginfo-tests project called DOC (Debugging Optimized Code) and start testing (and tracking) improvements in that area. WDYT?
Thanks for this! I am so exciting to see this implemented. :)
Tue, Sep 10
Fri, Sep 6
Is this OK to go?
@vsk Thanks a lot for the review!
Thanks for this! This looks good.
Thu, Sep 5
Thanks for this! As we have discussed before, this is desirable for sure.
-Add the documentation
-Add the test case
-Adjust the CMake
-Define and use a lambda expression to get the coverage bucket
Wed, Sep 4
Mon, Sep 2
-Use `print_function ` from `__future__`
Fri, Aug 30
- Simplify the code
-Fix the location stats output
@aprantl Thanks for the review!
Thu, Aug 29
-Verify only GNU extensions in this patch
@dstenb Thanks a lot for the test case, I will take a look into that.
Wed, Aug 28
@dstenb This is desirable! Thanks a lot for working on this! We also found such case when trying to add support for MIPS and we wanted to shared it, but it is good to see you also have found it!
@probinson Thanks a lot for your comments!
Tue, Aug 27
-Refactor the LocationStats struct
-Use the tempfile.TemporaryFile
-Use std::vector to map more debug location categories in order to have more granular reports
I have interpreted the size as meaning the byte size of the DWARF block that the operation will cover. Assuming that, at the time of running LiveDebugValues I don't think there is a good way to query the size of the block that the entry value will cover; we don't know that until we actually emit the DWARF, as far as I can tell. That is why I have assumed that a hard coded operand of 1 is emitted there, with the assumption that only simple register location descriptions are supported.
However, I now got uncertain when looking at prependOpcodes() which is used to add the operation to the DIExpression:
Add size info needed for entry value expression.
Add plus one for target register operand.
Ops.push_back(Expr->getNumElements() + 1);
Mon, Aug 26
Thanks for the patch.
We wanted to avoid any complex DIExpression here, so this looks good. In order to support it here, we need to add fully support within the AsmPrinter (DwarfDebug, DwarfExpression, DwarfCompileUnit) and then enable it here.
@yechunliang Thanks for the test case. Have you tried to simplify it?
Thu, Aug 22
I really like this approach. Thanks for doing this!
@vsk Thanks for your comments!
Wed, Aug 21
I am abandoning this and creating new revisions for the tool implemented as an utility (within utils/).
Thanks for this (a few comments added).
Thanks for this (just added a few nitpicks inside).
Aug 13 2019
Aug 7 2019
IIUC, I can abandon this patch and make a separate patch(es) for adding additional fields into the llvm-dwarfdump stats output, and then make a script (and put into the utils/) parsing the fields by doing the locstats job?
@MaskRay Thanks for your review! We are still discussing on the llvm-dev mailing list how we should continue with this. As soon as we finished, I will start cleaning up the code and addressing comments.
Aug 1 2019
@aprantl Thanks for your comment. WDYT about implementing this as a llvm-dwarfdump subtool?
Jul 31 2019
@vsk Thanks a lot!
@vsk Thanks for the comments!
Jul 29 2019
@vsk Thanks a lot for such nice review!
Jul 25 2019
@vsk Thanks! As soon as we re-land the callsiteparam work I will start cleaning up the code and up streaming it!
@vsk IIUC, you think the tool will be useful ? :)
I’ll set this patch aside for now.
I think the goal of this patch is desirable for sure. In addition, I am not opposed to coexisting of this kind of stats within both of the llvm-dwarfdump and llvm-locstats, but that can be a point of discussion.
Jul 24 2019
Thanks for working on this, it seems very useful! Any updates?
Jul 23 2019
@vsk Thanks for this! We have discussed about this on the other threads and the stats is useful for sure!
Having this stats gives us info about the "normal" (non-entry values) debug location coverage, because those locations with the entry value are useless if do not have proper call_site and call_site_paramters debug information generated in the .debug_info section.
Jul 12 2019
@uweigand Thanks for the note and comment!
@dstenb Thanks a lot, that seems useful!
-Make a wrapper around the getCallPreservedMask() and use it in order to avoid changes in generated code
Jul 11 2019
@dstenb Thanks a lot!
LGTM! Thanks @vsk!