<div dir="ltr">Yea, I can see splitting the target specific stuff into a separate "target aware" dump function and having the base one not require the exeuction context and go in Utility.  In the interest of not breaking anything it seems reasonable to try to do that as a separate patch so we the functional and non functional change portions can be separated from each other.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 3, 2017 at 9:51 AM 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">
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.<br class="gmail_msg">
<br class="gmail_msg">
We name functions starting with a Capitol first letter, so these should be "Dump..." not "dump...".  But other than that, this seems good.<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>