This is an archive of the discontinued LLVM Phabricator instance.

Split DataExtractor into two classes.
ClosedPublic

Authored by zturner on Mar 2 2017, 5:35 PM.

Details

Summary

The goal is to move DataBuffer, DataBufferLLVM, DataBufferHeap, DataExtractor, and DataEncoder from Core to Utility. All of this is a straightforward move except for DataExtractor, which has 3 methods which depend on the target and various debug info things.

The most sensible way I can come up with to do the split is to move those 3 functions into a subclass of DataExtractor, and update those callsites that use those 3 functions to use the new subclass.

After this change it should be a straightforward move to get the various DataBuffer and family classes into Utility.

Diff Detail

Event Timeline

zturner created this revision.Mar 2 2017, 5:35 PM
jingham added a subscriber: jingham.EditedMar 2 2017, 6:09 PM

Is it horrible of me to ask that we choose a name that is more descriptive than DataExtractorEx? That "Ex" extension to a class name is just such a punt, and I'd really rather not encourage it.

The subclass you made adds the ability to:

(a) Dump itself
(b) Extract some Dwarf EH Frame specific bits.

And (b) is only used in DwarfCallFrameInfo.cpp,

So it would be clearer to make a class that just does (a) and call it DataExtractorDumpable.

Then you could have a class override (like DataExtractorEH) local to DwarfCallFrameInfo.cpp that adds the GetGNUEHPointer. That latter seems awfully specific, and probably doesn't need to be sitting out in the general world. It certainly doesn't need to be riding along all the dumpable data extractors.

The EH stuff should definitely go in a specific subclass.

It also seems a shame to lose the capability to Dump DataExtractors in general. The only thing the exe_scope is used for in Dump (which is what is causing you problems) is to print instructions, and to do a more accurate job of printing non-native floats. It would be best to leave the Dump without these bits in the base data extractor, and return an error for the unsupported format kinds, and then add a Dump method that takes an exe_scope in the subclass (now DataExtractorTargetAware???)

zturner updated this revision to Diff 90432.Mar 2 2017, 9:45 PM

I basically turned the two dump methods into free functions and moved the DWARF specific function into DWARFCallFrameInfo.cpp. I think this is much better than before, as we don't muck with the inheritance hierarchy at all (removes a lot of code churn), and the header is very appropriately named.

labath edited edge metadata.Mar 3 2017, 5:24 AM

I like the free-standing function approach a lot.

Yes, that is a good solution. It's still a little awkward that DataExtractors live in Utility and their dumper lives in Core. Especially as almost all the functionality of the dumper could live in Utility. If you were serious about using Utility separate from Core you would want to put the non-target parts of DumpDataExtractor into Core and assert if those are passed the unsupported flavors, and then have DumpDataExtractorTarget, with the instruction and fancy float bits. But maybe that's work for another day.

We name functions starting with a Capitol first letter, so these should be "Dump..." not "dump...". But other than that, this seems good.

This revision was automatically updated to reflect the committed changes.