<div dir="ltr"><div dir="ltr">On Mon, Sep 13, 2021 at 11:42 AM <<a href="mailto:paul.robinson@sony.com">paul.robinson@sony.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-1999370702934879510WordSection1">
<p class="MsoNormal">+dblaikie who made DwarfCompileUnit final in c0bb21f3 (aka svn r301068)</p></div></div></blockquote><div><br>Yep, mostly because we didn't need it to be non-final (& would have to add a virtual destructor (to at least address the -Wnon-virtual-dtor warning, and to account for the possibility of further derived classes)).<br><br>Yeah, there'd need to be a bunch of conversations about what the entry points are to customizing DwarfDebug, etc. If you have to carry local patches to insert a different DwarfDebug implementation - including removing 'final' (& adding a virtual dtor) is your local patches probably isn't the worst thing - unlikely to be a high cost patch, I'd expect, compared to the other stuff needed. But open to understanding the use case.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-1999370702934879510WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I can certainly sympathize with wanting to keep your downstream separate from upstream llvm code!<u></u><u></u></p>
<p class="MsoNormal">Are you willing to describe some of your extensions?  That might help explain why subclassing DwarfCompileUnit is appropriate.<u></u><u></u></p>
<p class="MsoNormal">--paulr<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Youssefi, Anna via llvm-dev<br>
<b>Sent:</b> Monday, September 13, 2021 11:34 AM<br>
<b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> [llvm-dev] Vendor extensions to DWARF support<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I was wondering if anyone has recommendations on how best to implement Vendor extensions to DWARF support.  In particular, some of the functions I need to call are protected methods of the DwarfUnit class
<br>
(such as addAttribute()), but the DwarfCompileUnit subclass is final and can’t be extended, and making a new subclass of DwarfUnit appears to require overriding functions that we don’t need to override.  Currently I have added vendor-specific functions to DwarfCompileUnit,
 but as we like to keep our extensions separate from proper llvm code, this is less than ideal.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Anna Youssefi<u></u><u></u></p>
<p class="MsoNormal">Texas Instruments<u></u><u></u></p>
</div>
</div>
</div>

</blockquote></div></div>