I was actually thinking of making the dump functions free functions that take a const DataExtractor&.  This way the entire implementation could remain unchanged with the exception of replacing implicit member variable reads with reads through an explicit instance of the extractor.<br><br>This way we don't lose the ability to dump arbitrary DataExtractors and don't have to introduce a class for no practical benefit <br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 2, 2017 at 6:45 PM Jim Ingham via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">jingham added a comment.<br class="gmail_msg">
<br class="gmail_msg">
The EH stuff should definitely go in a specific subclass.<br class="gmail_msg">
<br class="gmail_msg">
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???)<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D30560" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D30560</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>