-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

This was reverted with the rL371527 due to test failure on Windows platform.

@dstenb Thanks for this! This makes sense.

I think that the problem described within the D67393 imposes a solution with introducing something like DBG_LOC, as @aprantl already suggested.

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. :)

Is this OK to go?

@vsk Thanks a lot for the review!

Thanks for this! This looks good.

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

• Simplify the code
• Rebase

-Fix the location stats output

@aprantl Thanks for the review!

-Verify only GNU extensions in this patch

@dstenb Thanks a lot for the test case, I will take a look into that.

@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!

-Refactor the LocationStats struct

-Rebase
-Use the tempfile.TemporaryFile
-Use subprocess.calll
-Use os.path.join

-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:

Ops.push_back(dwarf::DW_OP_entry_value);
Add size info needed for entry value expression.
Add plus one for target register operand.
Ops.push_back(Expr->getNumElements() + 1);

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?

@vsk

I really like this approach. Thanks for doing this!

Thanks!

@vsk Thanks for your comments!

The revisions are: D66525 and D66526.

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).

Thanks a lot for this! It looks reasonable to me.
(I am not sure if I can approve it, so please wait for @aprantl and @vsk too)

@aprantl, @vsk,
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.

@aprantl Thanks for your comment. WDYT about implementing this as a llvm-dwarfdump subtool?

@vsk Thanks a lot!

-Addressing comments

@vsk Thanks for the comments!

-Addressing comments

@vsk Thanks a lot for such nice review!

@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.

Thanks for working on this, it seems very useful! Any updates?

@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.

@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

@uweigand Thanks for that! The commit is reverted with the rL365886.

@dstenb Thanks a lot!

LGTM! Thanks @vsk!