As suggested in D149091, this makes working with data like CHPE much more readable.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/tools/yaml2obj/COFF/section-data.yaml | ||
---|---|---|
20 ↗ | (On Diff #518462) | I'm not sure I like the term Data, given that SectionData already exists. I'm guessing renaming SectionData to RawData is impractical due to the number of YAML files that would invalidate, but regardless, perhaps StructuredData might be a better name? |
25 ↗ | (On Diff #518462) | I'm not convinced both SectionData and Data should be specifiable for the same section. I think it makes more sense to reject the YAML if both are specified. |
Thanks for review. The new version uses StructuredData instead of Data and does not allow combining StructuredData and SectionData.
My original thinking was that while SectionData is there for backward compatibility, it's becoming redundant as one may use Data: -Binary: instead. A more explicit name sounds good to me too.
llvm/lib/ObjectYAML/COFFYAML.cpp | ||
---|---|---|
604 | Test case that shows this bit of code has changed (correctly)? |
Updated with missing tests. I also noticed that using uint32_t instead of int32_t would be better, so that we can cover call values with 0x constants.
Is there perhaps an argument for supporting both? uint32_t would certainly be my first choice, so I'm happy with just that, but if there's a case where the data might typically represent a negative value, it might make sense to support both. If there isn't a use-case though, it can be deferred until there is.
Anyway, LGTM in its current state.
llvm/lib/ObjectYAML/COFFYAML.cpp | ||
---|---|---|
552 | No more than food-for-thought, but should it be UInt32 (capitalized "i"), since it's an abbreviation of "unsigned int"? I don't have a strong opinion, so am happy with whatevere your preference is. |
I wasn't sure about capitalization when I wrote it. I still don't have a strong preference, but decided to change it to UInt32 after reconsideration.
A signed variant seems unlikely to be important in COFF context. I've been thinking about something like Zeroes (filling with specified number of zeroes) as another possible extension.
LGTM.
I'm happy to support any other extensions to this that prove useful. COFF yaml2obj is in need of a lot of love compared to the flexibility of ELF yaml2obj, so any improvements would be gratefully received.
llvm/lib/ObjectYAML/COFFYAML.cpp | ||
---|---|---|
604 | Tip, clicking the checkbox to mark a comment as "Done", prior to uploading the updated patch makes it easier to see if a comment has been addressed. |
No more than food-for-thought, but should it be UInt32 (capitalized "i"), since it's an abbreviation of "unsigned int"? I don't have a strong opinion, so am happy with whatevere your preference is.