This is an archive of the discontinued LLVM Phabricator instance.

[yaml2obj] Add support fot structured section data.
ClosedPublic

Authored by jacek on Apr 28 2023, 5:59 AM.

Details

Summary

As suggested in D149091, this makes working with data like CHPE much more readable.

Diff Detail

Event Timeline

jacek created this revision.Apr 28 2023, 5:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2023, 5:59 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
jacek requested review of this revision.Apr 28 2023, 5:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 28 2023, 5:59 AM
jacek updated this revision to Diff 518462.May 1 2023, 8:53 AM

A new version with yaml2obj.rst changes.

jhenderson added inline comments.May 31 2023, 7:55 AM
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.

jacek updated this revision to Diff 527401.Jun 1 2023, 6:51 AM

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.

jacek updated this revision to Diff 527405.Jun 1 2023, 7:04 AM

Updated documentation.

jacek updated this revision to Diff 536241.Jun 30 2023, 7:40 AM

Updated with additional use in arm64ec-chpe.yaml.

jhenderson added inline comments.Jul 3 2023, 12:34 AM
llvm/lib/ObjectYAML/COFFYAML.cpp
604

Test case that shows this bit of code has changed (correctly)?

jacek updated this revision to Diff 536891.Jul 3 2023, 2:10 PM

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.

jhenderson accepted this revision.Jul 4 2023, 12:07 AM

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.

This revision is now accepted and ready to land.Jul 4 2023, 12:07 AM
jacek updated this revision to Diff 537185.Jul 4 2023, 3:34 PM

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.

jhenderson accepted this revision.Jul 5 2023, 2:07 AM

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.

This revision was automatically updated to reflect the committed changes.