[PATCH] [MC] Disassembled CFG reconstruction

[Ahmed Bougacha]

On Thu, May 23, 2013 at 3:40 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> That makes sense, but in that case why not moving the buildFunction method
> in the MCModule.
>
> The thing is I do not like this mid-way approach: a MCModule does not known
> how to complete its internal representation.
> Let me give an example.
>
> Assume I want to build a MCModule.
> I call the MCOD buildModule (MCOD is a factory of MCModule, I am fine with
> that).
> I then give this MCModule to some other modules (I do not know what they
> want to do with it).
> Assume one of this module wants to use the MCFunctions supposedly contained
> in the MCModule... This is not obvious that it has to get a (similar) MCOD
> and uses it to complete its internal representation of a MCModule.
>
>  Another approach that is straightforward compared to the current patch is
> to directly returned a MCModule that has been build with the CFG.
> Thus, the ownership remains to the clients, but the returned MCModule is
> complete.
>
> If you think there may be clients that do not want the CFG, we can put a
> bool for that in buildModule.
> Regarding whether we should privatize buildCFG or not, I do not have a
> strong opinion, and in fact the answer is related to the previous question.
>
> What do you think?
>
> Quentin

Hiding buildCFG under a buildModule parameter makes perfect sense; I
think most clients won't need the CFG, as I'm hoping to make things
like llvm-objdump eventually use MCModule.

I'll go ahead and commit with this change then, thanks again!

-- Ahmed Bougacha