search for: dw_at_artifici

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

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

...: (indirect string, offset: 0x3e): Simple <70> DW_AT_byte_size : 1 <71> DW_AT_decl_file : 1 <72> DW_AT_decl_line : 1 [...] <3><7f>: Abbrev Number: 8 (DW_TAG_formal_parameter) <80> DW_AT_type : <0x86> <84> DW_AT_artificial : 1 <84> DW_AT_object_pointer: 1 <1><86>: Abbrev Number: 9 (DW_TAG_pointer_type) <87> DW_AT_type : <0x6b> The "this" parameter has type "Simple *" as expected, but also has the attribute DW_AT_object_pointer. My guess is that...

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

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

.../theclass.h") DW_AT_decl_line (12) DW_AT_type (0x000014e6 "string") DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) DW_TAG_formal_parameter DW_AT_type (0x0000371b "const foo*") DW_AT_artificial (true) NULL And as expected no further type information (aside from the destructor, also inlined). It seems gdb and lldb are able to find the full type definition even when there's a skeleton type. When exploring this with Paul, we worried a bit that LTO could de-duplicate to the ske...

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

...ate T> A::Foo(T t);". > > It's not just template functions, you know; the implicit ctors/dtors > might or might not be in any given description. Those are also only > instantiated and described in CUs that require them. We don't care about those as those are marked as DW_AT_artificial and we leave those out of the clang AST Context CXXRecordDecl because they are implicit and the compiler can add those back in if needed since it knows if a class can have the constructors implicitly created. > >> When we copy types between ASTs, everything is fine if the classes >&...

On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hey folks, > > > > Would you all mind having a bit of a design discussion around the > feature both at the DWARF level and the LLVM implementation? It seems like > what's

...t;> It's not just template functions, you know; the implicit ctors/dtors >>> might or might not be in any given description. Those are also only >>> instantiated and described in CUs that require them. >> >> We don't care about those as those are marked as DW_AT_artificial and we >> leave those out of the clang AST Context CXXRecordDecl because they are >> implicit and the compiler can add those back in if needed since it knows >> if a class can have the constructors implicitly created. >> >>> >>>> When we copy types b...

...arfUnit.cpp @@ -1518,6 +1518,9 @@ void DwarfUnit::applySubprogramAttributes(DISubprogram SP, DIE &SPDie) { constructSubprogramArguments(SPDie, Args); } + if(getCUNode().getEmissionKind() == DIBuilder::LineTablesOnly) + return; + if (SP.isArtificial()) addFlag(SPDie, dwarf::DW_AT_artificial); -------------- next part -------------- A non-text attachment was scrubbed... Name: funcs.cpp Type: text/x-c++src Size: 175 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140827/81edfe40/attachment.cpp> -------------- next part -------------- A no...

To elaborate a bit more on the issue that is detailed in https://reviews.llvm.org/rL260308: There are many clang AST contexts that are used in LLDB: - one for each lldb_private::Module that contains type definitions as we know them in the module and its symbol vendor - one for each expression - one for results of expressions in the lldb_private::Target As we run expressions we end up copying

I'm getting close to executing the transition to the new debug info hierarchy. For reference, I've attached two WIP patches (which would be squashed before commit) and the WIP upgrade script I'm using. - transition-code.patch: Change the `DIDescriptor` hierarchy to lightweight wrappers around the subclasses of `DebugNode` (instead of rather heavier wrappers around