search for: dw_tag_formal_parameter

...af): main <ba> DW_AT_decl_file : 1 <bb> DW_AT_decl_line : 16 <bc> DW_AT_prototyped : 1 <bc> DW_AT_type : <0x3f> <c0> DW_AT_external : 1 <c0> Unknown AT value: 3fe1: 1 <2><c0>: Abbrev Number: 8 (DW_TAG_formal_parameter) <c1> DW_AT_location : 0x23 (location list) <c5> DW_AT_name : (indirect string, offset: 0xc2): argc <c9> DW_AT_decl_file : 1 <ca> DW_AT_decl_line : 16 <cb> DW_AT_type : <0x3f> <2><cf>: Abbrev Num...

...to simplify the problem as much as possible.) I've carefully studied the source code of CGDebugInfo in clang as a working example. One puzzlement is that there's a discrepancy between what the "source level debugging with LLVM" docs say and what clang does: According to the docs, DW_TAG_formal_parameter is used to specify a formal parameter in a function type descriptor, but according to a code search, the name "DW_TAG_formal_parameter" does not appear anywhere in the clang source code. Instead, the argument array that is used when creating a function type descriptor contains only the ba...

...te 1 # DW_AT_prototyped .byte 1 # DW_AT_external .long .Lfunc_begin0 # DW_AT_low_pc .long .Lfunc_end0 # DW_AT_high_pc .byte 1 # DW_AT_frame_base .byte 85 .byte 5 # Abbrev [5] 0xd1:0xc DW_TAG_formal_parameter .byte 120 # DW_AT_name .byte 0 .byte 1 # DW_AT_decl_file .byte 11 # DW_AT_decl_line .long 92 # DW_AT_type .byte 2 # DW_AT_location .byte 145 .byte 120 .byte 0 # E...

...# DW_AT_external > .int Lfunc_begin0 # DW_AT_low_pc > .int Lfunc_end0 # DW_AT_high_pc > .byte 2 # DW_AT_frame_base > .byte 144 > .byte 60 > .byte 3 # Abbrev [3] 0x38:0xe > DW_TAG_formal_parameter > .int Linfo_string5 # DW_AT_name > .byte 1 # DW_AT_decl_file > .byte 2 # DW_AT_decl_line > .int 127 # DW_AT_type > .byte 2 # DW_AT_location > .byte 145 > .byte 24 > .byte 3...

...ia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal parameter > in a function type descriptor, but according to a code search, the name > "DW_TAG_formal_parameter" does not appear anywhere in the clang source code. > Instead, the argument array that is used when creating a function type > descriptor...

On Aug 31, 2010, at 9:03 AM, Talin wrote: > 4) What is the meaning of the "inlinedAt" argument for DebugLoc::get()? Does it mean the location where the inlined code was defined, or the location where it was expanded? the location where it was expanded - Devang

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

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

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

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

...: <1><6b>: Abbrev Number: 6 (DW_TAG_class_type) <6c> DW_AT_name : (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 *&qu...

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

Here are some issues that I am unclear about. What would be great is if the answers could be incorporated into the comments and documentation for DIFactory and DebugInfo.h: 1) What types of DIScope are valid arguments for DebugLoc::get()? The method takes an MDNode* argument, so looking at the function signature is no help. For example, DIFile is a subtype of DIScope, however looking at

...8164: strbeq r0, [r2, #0] 8166: moveq r0, #170 ; 0xaa 8168: pop {r4, r6, r7, pc} // a function return I have a variable *bar* and here's its corresponding DWARF DIE: <2><3b>: Abbrev Number: 3 (DW_TAG_formal_parameter) <3c> DW_AT_location : 0x0 (location list) <40> DW_AT_name : (indirect string, offset: 0x9e): *bar* <44> DW_AT_decl_file : 1 <45> DW_AT_decl_line : 34 <46> DW_AT_type : <0x153> // *Its location list* 000000...

...i32 1, metadata !9, null} As we can see 'c' parameter has been optimized and llvm.dbg.value is used to track its DWARF location. Now when I look at DWARF informations for object file using readelf --debug-dump, I've got for 'c' param: ... <2><81>: Abbrev Number: 3 (DW_TAG_formal_parameter) <82> DW_AT_name : c <84> DW_AT_decl_file : 1 <85> DW_AT_decl_line : 5 <86> DW_AT_type : <0x8d> <8a> DW_AT_location : 1 byte block: 54 (DW_OP_reg4) ... Looking at assembly code I've got: ... foo:...

...; > I've carefully studied the source code of CGDebugInfo in clang as a > working > > example. One puzzlement is that there's a discrepancy between what the > > "source level debugging with LLVM" docs say and what clang does: > According > > to the docs, DW_TAG_formal_parameter is used to specify a formal > parameter > > in a function type descriptor, but according to a code search, the name > > "DW_TAG_formal_parameter" does not appear anywhere in the clang source > code. > > Instead, the argument array that is used when creating a funct...

...v") 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_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 explor...

...trbeq r0, [r2, #0] > 8166: moveq r0, #170 ; 0xaa > 8168: pop {r4, r6, r7, pc} // a function return > > I have a variable bar and here's its corresponding DWARF DIE: > > <2><3b>: Abbrev Number: 3 (DW_TAG_formal_parameter) > <3c> DW_AT_location : 0x0 (location list) > <40> DW_AT_name : (indirect string, offset: 0x9e): bar > <44> DW_AT_decl_file : 1 > <45> DW_AT_decl_line : 34 > <46> DW_AT_type : <0x153> > >...

...8164: strbeq r0, [r2, #0] 8166: moveq r0, #170 ; 0xaa 8168: pop {r4, r6, r7, pc} // a function return I have a variable bar and here's its corresponding DWARF DIE: <2><3b>: Abbrev Number: 3 (DW_TAG_formal_parameter) <3c> DW_AT_location : 0x0 (location list) <40> DW_AT_name : (indirect string, offset: 0x9e): bar <44> DW_AT_decl_file : 1 <45> DW_AT_decl_line : 34 <46> DW_AT_type : <0x153> // Its location list 00000000 0...

...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) DW_AT_call_column (0x03) 0x00000088: DW_TAG_formal_parameter DW_AT_location (indexed (0x0) loclist = 0x00000010: [0x00000000004004c6, 0x00000000004004d4): DW_OP_explicit_pointer, DW_OP_lit3) DW_AT_abstract_origin (0x00000055 "p") ------------ Please note that DW_OP_explicit_...