[llvm-dev] Vendor extensions to DWARF support

[Youssefi, Anna via llvm-dev]

Ah, I see-I don't need to call that method directly, so that pretty much solves my problem.

Thanks, and sorry for the oversight.
Anna

From: paul.robinson at sony.com <paul.robinson at sony.com>
Sent: Monday, September 13, 2021 3:04 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

We provide a variety of addXxxx methods for a variety of different kinds of values; did we miss one?  For the case where you need addAttribute, what sort of form/value do you need?
--paulr

From: Youssefi, Anna <a-youssefi at ti.com<mailto:a-youssefi at ti.com>>
Sent: Monday, September 13, 2021 3:03 PM
To: Robinson, Paul <paul.robinson at sony.com<mailto:paul.robinson at sony.com>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; dblaikie at gmail.com<mailto:dblaikie at gmail.com>
Subject: RE: Vendor extensions to DWARF support

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<mailto:paul.robinson at sony.com> <paul.robinson at sony.com<mailto:paul.robinson at sony.com>>
Sent: Monday, September 13, 2021 1:43 PM
To: Youssefi, Anna <a-youssefi at ti.com<mailto:a-youssefi at ti.com>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; dblaikie at gmail.com<mailto: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/e4a07532/attachment.html>