similar to: [DebugInfo] Enabling constructor homing by default

On 03.09.2020 01:36, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 3:26 PM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 02.09.2020 21:44, David Blaikie wrote: >> >> >> On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com >> <mailto:avl.lapshin at gmail.com>>

On Fri, Nov 13, 2015 at 6:16 AM, <Peter_Marshall at sn.scee.net> wrote: > Hi Paul, > > Sorry for the delay, I've been out of the office. > > I think this example shows that name matching does not always work: > > template<typename T> class A { > public: > A(T val); > private: > T x; > }; > > struct B { > typedef

On Wed, Dec 9, 2015 at 10:40 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > That doesn't seem to be the DWARF I'm seeing from Clang (& it'd be > surprising if we used the typedef (or otherwise non-canonical) name in the > class name): > > > > Finally getting back to this….. Ha. We don't unwrap the typedefs ("name > as

On Wed, Dec 9, 2015 at 11:11 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Actually no, we prefer to have the original typedef names in the > instantiation name, for source fidelity. > Then perhaps you should keep this change in your tree too - since that's where the need is? > "Name as it is in the source" or something reasonably close.

Hello folks, I was interested in the support we have for the attribute form DW_FORM_implicit_const (DWARFv5 feature) in clang/LLVM. And I had some doubts wrt this. I noticed that support for this was put in here in 2017: https://rev.ng/gitlab/revng-bar-2019/llvm/commit/d9df13befcbc702e239b650dd1f55778d72b8571 >From what I could make out, the support for generating DW_FORM_implicit_const

On Wed, Dec 9, 2015 at 11:59 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote: > Maybe we are being too pedantic about the names. I'll have to go back and > look in detail at why we decided to do that. > > > > In any case, arguably 5.5.8 (Class Template Instantiations) 1 only applies > to definitions of a type, not declarations. ("Each formal

Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow... >Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)? > - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc. There are two general requirements: 1) Remove (or clean) invalid

In an effort to fix inlined information for backtraces under DWARF Fission in the absence of the split DWARF (.dwo) files, I'm planning on adding -gmlt-like data to the .o file, alongside the skeleton CU. Since that will involve teaching the LLVM about -gmlt (moreso than it already has - the debug info LLVM metadata already describes -gmlt for the purposes of omitting pubnames in that case) I

On 02.09.2020 21:44, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 01.09.2020 20:07, David Blaikie wrote: >> Fair enough - thanks for clarifying the differences! (I'd still >> lean a bit towards this being dwz-esque, as you say "an

Bunch of initially unrelated context: * type units can be referenced in a variety of ways: * DW_FORM_ref_sig8 on any attribute needing to reference the type * DW_AT_signature on a declaration of the type * extra wrinkle: the declaration can be nested into the appropriate namespace and given a name, or not * LLVM always does the "most expressive"/expensive thing: a full

On Thu, Aug 28, 2014 at 11:51 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > This sounds great. Teaching backend about the -gmlt might help us in > another way: we might enforce full debug info generation in the frontend > for -fsanitize= flags, then rely on some parts of this debug info in > instrumentation passes and prune it before the actual object file >

Hi all, As you may know modern C++ debuggers (GDB and LLDB) support dynamic type identification for polymorphic objects, by utilizing C++ RTTI. Unfortunately this feature does not work with Clang and GDB >= 7.x . The last compiler that worked well was G++ 6.x I've asked about this issue both on GDB and LLDB maillists. Unfortunately it's hard or impossible to fix it on debugger side.

Mangled names can be long indeed, but pretty-printed types are also long. I can evaluate effect on size on clang codebase itself. If you disable RTTI, than obviously you can't use it. So if RTTI is disabled, we can disable mangled names in DWARF. Clang is compiled without standard C++ RTTI because it has it's own RTTI. In general, however, many libraries use standard RTTI. 2018-03-02

Hi Karthik, > Expected result when we run - > > print Simple::fun in GDB is > void fun(Simple* const this) > > as this should be a const pointer but in case of arm compiled binary we get > void fun(Simple* this). I believe the actual type is coming from CXXMethodDecl::getThisType, which quotes the standard as saying: // C++ 9.3.2p1: The type of this in a member function

Here is result of experiment: (Original size , with DW_AT_linkage_name for composites, % increase) clang-7.0 1926574256 1952846192 1.4% clang-tidy 1220980360 1238498112 1.4% llvm-mt 7404728 7525328 1.6 % std::cout << "hello world!" 21552 22080 2.4 % IMO, not that big price for reliable dynamic type identification (Full disclosure: I need depend on this feature, since

> Currently what debugger has to do is to demangle RTTI name and try to > match it to DW_AT_name attribute to find type. As you can see it does > not work for any of 3 examples. > > I've asked about the problem on G++ maillist, and one of the proposed > solutions is to emit DW_AT_linkage_name for types.  > > Can this solution be also implemented in LLVM?  It could, but

Hi All, Was looking into a simple program - class Simple { public: void fun() {} }; int main() { Simple s; s.fun(); return 0; } When compiled using clang++ for ARM- Expected result when we run - print Simple::fun in GDB is void fun(Simple* const this) as this should be a const pointer but in case of arm compiled binary we get void fun(Simple* this). Works fine when compiled using

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via

On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > As you may know modern C++ debuggers (GDB and LLDB) support dynamic type > identification for polymorphic objects, by utilizing C++ RTTI. > Unfortunately this feature does not work with Clang and GDB >= 7.x . The > last compiler that worked well was G++ 6.x >

Folks, we work on optimization of binary size and improvement of debug info quality. To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected. When the linker does garbage collection, a lot of abandoned debug info is left behind. Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage