search for: dw_at_linkage_nam

...ursuing any further. An API to use that form explicitly (that isn't the normal debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings are concerned: DWARF 5 will ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs that had DW_AT_linkage_name without DW_AT_name; it can happen, though, so the number of variable-size DIEs i...

...DW_AT_name: foo<EN::ONE> 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? I've checked LLVM docs and found out that LLVM generates DWARF from LLVM metadata. LLVM metadata for types already contains linkage name in "identifier" field: https://llvm.org/docs/LangRef.html#dicompositetype So LLVM itse...

...bugger 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 mangled names can be very long and we need to consider > whether the additional size cost is worth it under various conditions. > For example, does this type matching work when a program is...

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

We're inconsistent about using DW_AT_MIPS_linkage_name versus DW_AT_linkage_name. Variables (see DwarfCompileUnit::getOrCreateGlobalVariableDIE()) get the standard attribute for DWARF >= 4, MIPS for older. Subprograms (see DwarfUnit::applySubprogramDefinitionAttributes()) always get DW_AT_MIPS_linkage_name (no version check). Before I go drudging through however many tes...

...llvm-dwarfdump, I can see that the debug information for fqux clearly lists the location as well. 0x00000918: DW_TAG_subprogram DW_AT_low_pc (0x00000000004207c8) DW_AT_high_pc (0x0000000000420817) DW_AT_frame_base (DW_OP_reg7 RSP) DW_AT_linkage_name ("fqux") DW_AT_name ("fqux") DW_AT_decl_file ("TODO/llvm.hs") DW_AT_decl_line (8) DW_AT_external (true) I suspect this is a problem with the DWARF information as when I try to use `llvm-symboliser` wi...

> 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 mangled names can be very long and we need to consider whether the additional size cost is worth it under various conditions. For example, does this type matching work when a program is compiled with `-fno-rtti`?...

...GDB :) 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? > Please, no. This is completely unneeded and wastes a huge amount of space. As you can see from the replies to my solution on the gdb mailing list, it is used by other languages (rust, for example) *anyway*, so we might as...

..._TAG_structure_type <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<                 DW_AT_name      ("foo")                 DW_AT_byte_size (0x01) 0x000000b7:     DW_TAG_subprogram                   DW_AT_linkage_name    ("_ZN3foo3fffIiEEiv")                   DW_AT_name    ("fff<int>") 0x0000011f: DW_TAG_compile_unit               DW_AT_language    (DW_LANG_C_plus_plus)               DW_AT_name        ("mod2.cpp") 0x00000177:   DW_TAG_structure_type <<<<&l...

...ee above. Looks like this information is not necessary. > Perfect. > > >> >> (one other thing I noticed is that we don't use the mangled names for >> functions in -gmlt - how on earth does that work? >> > > Yeah, IIRC currently -gmlt doesn't produce DW_AT_linkage_name entries, > only DW_AT_name (DW_AT_linkage_name signifincantly increases the binary > size for heavily templated code). So, instead of Foo::Bar<double>::Baz we > have only "Baz". And we live with that - we fetch just "Baz" from > subprogram entries. If a functi...

...on for fqux clearly lists the location as well. >> >> 0x00000918: DW_TAG_subprogram >> DW_AT_low_pc (0x00000000004207c8) >> DW_AT_high_pc (0x0000000000420817) >> DW_AT_frame_base (DW_OP_reg7 RSP) >> DW_AT_linkage_name ("fqux") >> DW_AT_name ("fqux") >> DW_AT_decl_file ("TODO/llvm.hs") >> DW_AT_decl_line (8) >> DW_AT_external (true) >> >> I suspect this is a problem with the DWARF inf...

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

...ns if functions have an inlined copy in the translation unit. For example in [0] where I've uploaded a couple of dexter tests for constructor homing, in partial-type/main.cpp we get: DW_TAG_class_type DW_AT_name ("foo") DW_AT_declaration (true) DW_TAG_subprogram DW_AT_linkage_name ("_ZNK3foo8asStringB5cxx11Ev") DW_AT_name ("asString") DW_AT_decl_file ("./theclass.h") DW_AT_decl_line (12) DW_AT_type (0x000014e6 "string") DW_AT_declaration (true) DW_AT_external (true) DW_AT_acc...

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

...at 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? >> > > Please, no. > > This is completely unneeded and wastes a huge amount of space. > > As you can see from the replies to my solution on the gdb mailing list, it > is used by other languages (...

...gt; >> >> >> 0x00000918: DW_TAG_subprogram >> >> DW_AT_low_pc (0x00000000004207c8) >> >> DW_AT_high_pc (0x0000000000420817) >> >> DW_AT_frame_base (DW_OP_reg7 RSP) >> >> DW_AT_linkage_name ("fqux") >> >> DW_AT_name ("fqux") >> >> DW_AT_decl_file ("TODO/llvm.hs") >> >> DW_AT_decl_line (8) >> >> DW_AT_external (true) >> >> >> &g...

Hello, Thanks for prompt reply. Motivation, In case of debugging of bi-endian dwarf and value known at runtime some of the raw values needs to be byte swapped to change the endianity. We have a llvm based compiler which generates such dwarf, TAG_variable marked as big endian and debugging on little endian host using lldb. The listed operator on dwarf issues does that, one operator instead of

>From my understanding, the LLVM classes are just representing the DWARF information without doing any extra work, so I am afraid that you will have to explicitly chase through all the DWARF information yourself. On 4/5/2018 3:22 PM, Bill O'Hara via llvm-dev wrote: > Hi > > I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on > some shared libraries, I

Hi I was wondering whether I can extract the function signature from the dwarf debugging information or symbol table. I mean the argument list and the return variables. I know that in dwarf debugging information, a subprogram represents a function. However, I could not find the information that is related to the function signature. Any ideas? Many Thanks Regards Muhui -------------- next part

Hi I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on some shared libraries, I see I can print the debug info (assuming it exists). For some function, I'm wondering if there's a short cut to prettyprinting the signature of a function in the library? I think, looking at the output, that enough information exists but it seems to involve looking at the subprogram