search for: dw_at_abstract_origin

...represented entity, except for the local variable that will be missing the location attribute (DW_AT_location), as it is not common to all inline/concrete functions. In addition, under each lexical block entry in the inline/concrete function entry there will be: 1. Abstract origin attribute (DW_AT_abstract_origin) pointing to the equivalent lexical block entry in the abstract function. 2. Local variable entry - with abstract origin attribute pointing to the one in the abstract function, and also the location attribute. (1) DW_TAG_subprogram (abstract) DW_AT_name (= "foo") DW_AT_inline...

On Mon, Dec 14, 2015 at 7:01 AM, Aboud, Amjad via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I verified that GDB 7.10 does support “DW_AT_abstract_origin” attribute on > “DW_TAG_lexical_block”. > I take it you mean that it does the right thing, finding the direct children of the abstract block when stepping into the inlined subroutine, etc? & this was a recent change/fix - because you'd verified that this did not work previously/in r...

...Does it matter? So my really rough prototype (that just used the first CU in the CUMap for all subprograms) of course ended up with this: DW_TAG_compile_unit DW_TAG_subprogram #0 DW_AT_name "f2" DW_TAG_subprogram DW_AT_name "c1" DW_TAG_inlined_subroutine DW_AT_abstract_origin #0 DW_TAG_subprogram DW_AT_name "c2" DW_TAG_inlined_subroutine DW_AT_abstract_origin #0 DW_TAG_compile_unit So I suppose we could use the unit when present - and make it present (& use distinct) when the function definition has external linkage. There's nothing we...

...he >> out of line definition (if there is one?) of the inlined function (in which >> case I'd need to provide it... ) to find it in the symbol table, get the >> mangled name, and use that?) >> >> One thing I was thinking of doing as well, is that since the >> DW_AT_abstract_origin just points to a trivial subprogram with a name and >> DW_AT_inline - perhaps instead of an abstract origin, we could just use >> DW_AT_name directly? (with the mangled name, probably) That'd save us >> emitting the extra indirection and the name is uniqued already anyway. (an...

...promoted. For such cases it generates IR as call void @llvm.dbg.derefval(metadata i32 3, metadata !25, metadata !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32 And llvm-darfdump output looks like ------------- 0x0000007b: DW_TAG_inlined_subroutine DW_AT_abstract_origin (0x0000004f "_Z4sinkRKi") DW_AT_low_pc (0x00000000004004c6) DW_AT_high_pc (0x00000000004004d0) DW_AT_call_file ("/home/alok/openllvm/llvm-project_derefval/build.d/david.cc") DW_AT_call_line (10)...

...lvm.dbg.derefval(metadata i32 3, metadata !25, metadata >> !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32 >> >> And llvm-darfdump output looks like >> >> ------------- >> 0x0000007b: DW_TAG_inlined_subroutine >> DW_AT_abstract_origin (0x0000004f "_Z4sinkRKi") >> DW_AT_low_pc (0x00000000004004c6) >> DW_AT_high_pc (0x00000000004004d0) >> DW_AT_call_file >> ("/home/alok/openllvm/llvm-project_derefval/build.d/david.cc") >>...

...s - or does the symbolizer use the address range of the out of line definition (if there is one?) of the inlined function (in which case I'd need to provide it... ) to find it in the symbol table, get the mangled name, and use that?) One thing I was thinking of doing as well, is that since the DW_AT_abstract_origin just points to a trivial subprogram with a name and DW_AT_inline - perhaps instead of an abstract origin, we could just use DW_AT_name directly? (with the mangled name, probably) That'd save us emitting the extra indirection and the name is uniqued already anyway. (and DW_FORM_strp is the same...

...he children and // object pointer later on. But what we don't want to do is process the // concrete DIE twice. if (DIE *AbsSPDIE = AbstractSPDies.lookup(SPNode)) { // Pick up abstract subprogram DIE. SPDie = new DIE(dwarf::DW_TAG_subprogram); SPCU->addDIEEntry(SPDie, dwarf::DW_AT_abstract_origin, dwarf::DW_FORM_ref4, AbsSPDIE); SPCU->addDie(SPDie); } … } The compile unit DIE where AbsSPDIE belongs to is different from the compile unit DIE SPCU->getCUDie(). So it is not legal to use a FORM_ref4 here. Why do we create these subprogram DIEs here? They are a...

...("res") >> DW_AT_decl_file ("ref.cc") >> DW_AT_decl_line (12) >> DW_AT_type (0x00000037 "int") >> >> 0x00000091: DW_TAG_inlined_subroutine >> DW_AT_abstract_origin (0x0000004f "_Z4funcRi") >> DW_AT_low_pc (0x0000000000400490) >> DW_AT_high_pc (0x000000000040049a) >> DW_AT_call_file ("ref.cc") >> DW_AT_call_line (12) >>...

...occurs without error and the subsequent compilation also seems to go fine, but when the resultant llvm-dwarfdump -verbose -verify is run I get a bunch of the following errors: warning: could not find referenced DIE in DIE: 0x0000a33f: DW_TAG_inlined_subroutine [20] * DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x0c84 => {0x0000a40d}) DW_AT_ranges [DW_FORM_sec_offset] (0x00021960 [0x0000000000001878 - 0x000000000000187c) [0x00000000000018b0 - 0x0000000000001910) [0x0000000000001980 - 0x00000000...

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

...>>>> !DIExpression(DW_OP_LLVM_explicit_pointer, DW_OP_LLVM_arg0)), !dbg !32 >>>> >>>> And llvm-darfdump output looks like >>>> >>>> ------------- >>>> 0x0000007b: DW_TAG_inlined_subroutine >>>> DW_AT_abstract_origin (0x0000004f "_Z4sinkRKi") >>>> DW_AT_low_pc (0x00000000004004c6) >>>> DW_AT_high_pc (0x00000000004004d0) >>>> DW_AT_call_file >>>> ("/home/alok/openllvm/llvm-project_derefval/build....

> 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 already been made to DISubprogram. > > To reduce duplicate debug info when things like linkonce_odr functions were

...E = *new* DIE(dwarf::DW_TAG_inlined_subroutine); DISubprogram InlinedSP = getDISubprogram(DS); CompileUnit *TheCU = getCompileUnit(InlinedSP); DIE *OriginDIE = TheCU->getDIE(InlinedSP); assert(OriginDIE && *"Unable to find Origin DIE!"*); addDIEEntry(ScopeDIE, dwarf::DW_AT_abstract_origin, *dwarf*::DW_FORM_ref4, OriginDIE); What's happening is that InlinedSP.DbgNode is NULL, which causes getCompileUnit() to assert. Note that this occurs in both llc and my linker (tartln) because they both use the same set of passes to generate machine code. So basically whenever...

...: 0xf4): children <414> DW_AT_decl_file : 1 <415> DW_AT_decl_line : 19 <416> DW_AT_type : <0x591> <41a> DW_AT_location : 0x13f (location list) <2><41e>: Abbrev Number: 24 (DW_TAG_inlined_subroutine) <41f> DW_AT_abstract_origin: <0x305> <423> DW_AT_low_pc : 0x4008ab ...(more information for main)... The "children" variable has a location list, and "I" is not listed as having a constant value. Note that if I compile with clang using -O0, there's a location list for both &quo...

...-- > [ 1314s] > /home/abuild/rpmbuild/BUILD/llvm/test/DebugInfo/missing-abstract-variable.ll:74:10: > error: expected string not found in input > [ 1314s] ; CHECK: DW_TAG_formal_parameter > [ 1314s] ^ > [ 1314s] <stdin>:85:67: note: scanning from here > [ 1314s] DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x002a => {0x0000002a}) > [ 1314s] ^ > [ 1314s] <stdin>:91:13: note: possible intended match here > [ 1314s] 0x000000b7: DW_TAG_lexical_block [8] * > [ 1314s] ^ > [ 1314s] >...

----- Original Message ----- > From: "İsmail Dönmez" <ismail at donmez.ws> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, May 12, 2014 7:18:48 AM > Subject: Re: Lots of regtest failures on PPC64/Linux > > > Hi Hal, > > > > > > On

Hi, [ I think I put the most important contributors to the DebugInfo stuff in Cc:. Is there anyone else that I am missing? ] Just a short notice that I am currently working on making llvm-dwarfdump more developer friendly. There are quite a few features in Darwin’s dwarfdump that we find quite useful and that we would like to contribute to llvm-dwarfdump. I have started by augmenting the

...occurs without error and the subsequent compilation also seems to go fine, but when the resultant llvm-dwarfdump -verbose -verify is run I get a bunch of the following errors: warning: could not find referenced DIE     in DIE: 0x0000a33f:      DW_TAG_inlined_subroutine [20] *                     DW_AT_abstract_origin [DW_FORM_ref4]    (cu + 0x0c84 => {0x0000a40d})                     DW_AT_ranges [DW_FORM_sec_offset]    (0x00021960                       [0x0000000000001878 - 0x000000000000187c)                       [0x00000000000018b0 - 0x0000000000001910)                       [0x0000000000001980 - 0x00000...

> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt? Below