<div dir="ltr">On Fri, Sep 13, 2013 at 11:56 AM, Thirumurthi, Ashok <span dir="ltr"><<a href="mailto:ashok.thirumurthi@intel.com" target="_blank">ashok.thirumurthi@intel.com</a>></span> wrote:<br><div class="gmail_extra">

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Great work on the refactoring, Mike, it's really a solid and thoughtful effort and should move us in the direction of loading an ELF core on OS/X.  Everything looks good and tests well, but I see that you also reinvented the container for RegisterInfo:<br>


<div class="im"><br>
// Use a singleton function to avoid global constructors in shared libraries.<br>
</div>RegisterContextFreeBSD_x86_64::RegisterContextFreeBSD_x86_64()<br>
{<br>
<div class="im">    static std::vector<RegisterInfo> g_register_infos;<br>
</div>    return g_register_infos;<br>
}<br>
<br>
--><br>
<div class="im"><br>
   std::vector<lldb_private::RegisterInfo> m_register_infos<br>
<br>
</div>The resulting code is very readable and maintainable, which is a great asset.  I took the same path myself until I realized that the static register set is more efficient.  Essentially, we frequently create a RegisterContext (i.e. each frame of each thread is a candidate), however once the architecture is known, the register information can be pinned down once for all frames.  Hence all the hoops to allow a class hierarchy to use a static container.<br>


<br>
Is this something that you could restore in a separate commit?  Thanks,</blockquote><div><br></div><div>How does this look Ashok?</div><div><br></div><div><a href="http://llvm-reviews.chandlerc.com/D1703">http://llvm-reviews.chandlerc.com/D1703</a> </div>

<div><br></div><div>Thanks.</div><div> -Mike</div></div></div></div>