The implementation is a pretty straightforward extension of the pattern
used for (de)serializing the ModuleList stream. Since there are other
streams which use the same format (MemoryList and MemoryList64, at
least). I tried to generalize the code a bit so that adding future
streams of this type can be done with less code.
Details
- Reviewers
amccarth jhenderson clayborg - Commits
- rZORGcb148adb0402: MinidumpYAML: add support for the ThreadList stream
rZORGd2831be84518: MinidumpYAML: add support for the ThreadList stream
rGcb148adb0402: MinidumpYAML: add support for the ThreadList stream
rGd2831be84518: MinidumpYAML: add support for the ThreadList stream
rGdcdb3c6650e6: MinidumpYAML: add support for the ThreadList stream
rL360350: MinidumpYAML: add support for the ThreadList stream
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 31270 Build 31269: arc lint + arc unit
Event Timeline
include/llvm/ObjectYAML/MinidumpYAML.h | ||
---|---|---|
57 | with -> with a | |
58 | KindV and TypeV aren't clear names to me. What does the V stand for? | |
64 | explicit? | |
70–73 | I'm not sure how much sense it makes to go into the detail of the minidump file format versus the memory view here. I also am not convinced by the repetition of this in the comments below. | |
lib/ObjectYAML/MinidumpYAML.cpp | ||
481 | Same comment as above re. names. | |
test/tools/obj2yaml/basic-minidump.yaml | ||
47–49 | It would be nice if these were padded so that they all line up. Ditto in the Stack block below. | |
51 | I don't have a concrete suggestion, but it might be nice to have a shorter field name than "Start of Memory Range", but that's less of a concern if that's the actual minidump field name. |
include/llvm/ObjectYAML/MinidumpYAML.h | ||
---|---|---|
58 | "variable" or "value" or something like that. :) Not a very good name, but I needed to differentiate that from the class member with the same name. However, just I've had an idea of how to organize this better and reduce the number of template parameters (by making these static members of the EntryT type). This also avoid the need for inventing names here. | |
70–73 | I've removed the memory vs. file blurb. | |
test/tools/obj2yaml/basic-minidump.yaml | ||
47–49 | The microsoft structure definition calls this field just "teb" (for Thread Environment Block), but I've found that too opaque, so I expanded the acronym (sans "thread", because it is obvious we are talking about threads here). I could shorten this further to "environment" (the word "block" probably doesn't add that much value) , or even to "teb" for consistency with microsoft headers. Let me know what you think. | |
51 | That's how the field is called in the official microsoft documentation (https://docs.microsoft.com/en-us/windows/desktop/api/minidumpapiset/ns-minidumpapiset-minidump_memory_descriptor), which is probably the closest thing to a "spec" for this thing. It's a bit verbose, and probably "Address" would just suffice here, but otoh it's nice for this to match the official name. |
LGTM, with the suggested fixes.
test/tools/obj2yaml/basic-minidump.yaml | ||
---|---|---|
47–49 | Environment Block is fine. I was actually referring to the number of spaces between the attribute name and value, i.e. I'd prefer this: - Thread Id: 0x5C5D5E5F Priority Class: 0x60616263 Environment Block: 0x6465666768696A6B | |
51 | Let's leave it as is, since it matches the Microsoft document. | |
105 | Similar comment here about whitespace. Make the values of attributes within a block line up. | |
106 | Move this to be above the Stack block for readability. |
Thanks for the review.
test/tools/obj2yaml/basic-minidump.yaml | ||
---|---|---|
47–49 | Ok, I see. I can do that manually here, but that won't prevent the actual output from obj2yaml from being misaligned (which is why i was trying to come up with a shorter name). |
with -> with a