llvm dev - Sep 2021 - Vendor extensions to DWARF support

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

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/35e4235a/attachment.html>

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>

We are adding the generation of one TI-specific dwarf tag and 3 dwarf
attributes, in order to use our stack analyzer which relies on these dwarf tags
& attributes.

One function calls the following functions in order to add the TI-specifc call
tag and either the indirect call attribute, or the direct call attribute along
with name attribute for the callee.  . It looks like only the addAttribute
function is protected:

createAndAddDIE (public method of DwarfUnit)
addLabelAddress  (public method of DwarfCompileUnit)
addAttribute (protected method of DwarfUnit)
addString (public method of DwarfUnit)


The second function just calls addUInt() (public method of DwarfUnit) to use add
our frame size attribute to the existing Subprogram Die.

Additionally, I duplicated code from the DwarfDebug::constructCallSiteEntryDIE
function in order to make these calls without mucking with the existing
function.  Note we do not currently support DWARF5 so this function doesn't
get called for the TI Arm Clang compiler.

From: paul.robinson at sony.com <paul.robinson at sony.com>
Sent: Monday, September 13, 2021 1:43 PM
To: Youssefi, Anna <a-youssefi at ti.com>; llvm-dev at lists.llvm.org;
dblaikie at gmail.com
Subject: [EXTERNAL] RE: Vendor extensions to DWARF support

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

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<mailto: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<mailto: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/b037fe95/attachment.html>