[llvm-dev] Vendor extensions to DWARF support

[David Blaikie via llvm-dev]

On Mon, Sep 13, 2021 at 11:42 AM <paul.robinson at sony.com> wrote:

> +dblaikie who made DwarfCompileUnit final in c0bb21f3 (aka svn r301068)
>

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)).

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.


>
>
> I can certainly sympathize with wanting to keep your downstream separate
> from upstream llvm code!
>
> Are you willing to describe some of your extensions?  That might help
> explain why subclassing DwarfCompileUnit is appropriate.
>
> --paulr
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Youssefi,
> Anna via llvm-dev
> *Sent:* Monday, September 13, 2021 11:34 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] Vendor extensions to DWARF support
>
>
>
> Hi,
>
>
>
> 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
> (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.
>
>
>
> Thanks,
>
> Anna Youssefi
>
> Texas Instruments
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210913/ede1647c/attachment.html>