search for: dw_at_byte_size

.... Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following: 0x00000296: DW_TAG_base_type [10] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] = "void") DW_AT_encoding [DW_FORM_data1] (0x00) DW_AT_byte_size [DW_FORM_data1] (0x00) .... 0x00000cf8: DW_TAG_subprogram [16] * DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) DW_AT_high_pc [DW_FORM_data4] (0x000002b4) DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 ) DW_AT_name...

...4 DW_AT_type <144> DW_AT_location DW_OP_fbreg 0 <1>< 134> DW_TAG_base_type DW_AT_name int DW_AT_encoding DW_ATE_signed DW_AT_byte_size 4 <1>< 141> DW_TAG_base_type DW_AT_byte_size 4 DW_AT_encoding DW_ATE_signed <1>< 144> DW_TAG_array_type DW_AT_type <134> <2>< 149> DW_...

...4 DW_AT_type <144> DW_AT_location DW_OP_fbreg 0 <1>< 134> DW_TAG_base_type DW_AT_name int DW_AT_encoding DW_ATE_signed DW_AT_byte_size 4 <1>< 141> DW_TAG_base_type DW_AT_byte_size 4 DW_AT_encoding DW_ATE_signed <1>< 144> DW_TAG_array_type DW_AT_type <134> <2>< 149> DW_...

...> .byte 145 > .byte 8 > .byte 0 # End Of Children Mark > .byte 5 # Abbrev [5] 0x7f:0x7 DW_TAG_base_type > .int Linfo_string4 # DW_AT_name > .byte 5 # DW_AT_encoding > .byte 4 # DW_AT_byte_size > .byte 5 # Abbrev [5] 0x86:0x7 DW_TAG_base_type > .int Linfo_string7 # DW_AT_name > .byte 6 # DW_AT_encoding > .byte 1 # DW_AT_byte_size > .byte 6 # Abbrev [6] 0x8d:0x5 DW_TAG_pointer...

..., but always stores as 16 bytes). As far as I see it, there's 3 questions here: 1) What's the right representation in DWARF? 2) If we think it should be the byte_size/bit_size combination, how do we describe this in IR, because right now, even though the size is in bits, will always emit `DW_AT_byte_size $(size>>3)` 3) How would clang describe this in it's TargetInfo Just to throw my opinion out there: 1) Use the DW_AT_bit_size/DW_AT_byte_size 2) Add a new `storage_size` attribute to DIBaseType that is generally equal to size, except in cases like this, where we should have `storage_siz...

...ld not make out the DWARF attributes for which this form is being generated currently. Are there any attributes for which this form is generated currently ? Gcc typically generates this form for a bunch of attributes like: DW_AT_decl_file, DW_AT_decl_column, DW_AT_accessibility, DW_AT_defaulted, DW_AT_byte_size, etc Any pointers are deeply appreciated. Thanks, Jini. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191105/32ebf5df/attachment.html>

...t; | Unfortunately impossible/hard to answer. DWARF is fairly flexible & >> doesn't dictate "right" answers, as such. >> >> This time, actually the "right" answer is fairly clear (and in normative >> text, no less) right there in section 5.1. Use DW_AT_byte_size for the >> storage size and DW_AT_bit_size for the value size. >> > > I'm not sure - it seems like a valid interpretation to believe that the > value is 128 bits - some of those bits are always zero. (& of course the > DWARF spec says "the base type entry /may/...

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

...t;48> DW_AT_name : (indirect string, offset: 0xe3): x <4c> DW_AT_type : <0x6d> ... ... <2><5f>: Abbrev Number: 5 (DW_TAG_enumeration_type) <60> DW_AT_name : (indirect string, offset: 0x140): .llvm.aux.attr <64> DW_AT_byte_size : 0 <3><65>: Abbrev Number: 6 (DW_TAG_enumerator) <66> DW_AT_name : (indirect string, offset: 0x13c): .ID <6a> DW_AT_const_value : 1234 By DW_TAG_enumeration_type '.llvm.aux.attr', we can connect an attribute named ".ID" to this struc...

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

...nit-relative offsets instead? I've prototyped this and end up with output something like this: 0x00000051: DW_TAG_base_type [24] DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000051] = "int") DW_AT_encoding [DW_FORM_data1] (0x05) DW_AT_byte_size [DW_FORM_data1] (0x04) 0x00000058: NULL 0x000001ec: Compile Unit: length = 0x0000002b version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0000021b) 0x0000000b: DW_TAG_type_unit [25] * DW_AT_language [DW_FORM_data2] (0x0004) 0x0000000e: DW_TAG_namespace [9]...

...However, when I print out the debugging information via dwarfdump, you can see that the size of the object is zero: <1>< 2233> DW_TAG_class_type DW_AT_sibling <2295> DW_AT_name tart.core.Object * DW_AT_byte_size 0* DW_AT_decl_file 65 DW_AT_decl_line 9 <2>< 2258> DW_TAG_member DW_AT_name __tib DW_AT_type <2228> DW_AT_decl_file...

...#39;s the gdb programs that are printing different things for the same DWARF debug information. Dumping the information from the x86 binary gives: <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...

...in the debug info. We might have to special case this in the verifier, but before we do that, I wanted to ask about the following: Reading the DWARF standard, it seems like the following would be a valid description of an X86 80bit long double: DW_TAG_base_type DW_AT_name "long double" DW_AT_byte_size 16 DW_AT_bit_size 80 As far as I can tell from looking through the source code, both LLDB and GDB would read this just fine, it would be a more accurate description of a long double and if we add support for it in LLVM IR, the verifier would be able to understand what's actually going on...

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

...aps to the DWARF tag, DW_TAG_string_type. We have added a new named DI to LLVM to generate this DWARF information. !21 = !DIStringType(name: “character(5)”, size: 40) This produces the following DWARF information. DW_TAG_string_type: DW_AT_name: “character(5)” DW_AT_byte_size: 5 CHARACTER types can also have deferred length. This is supported in the new metadata as follows. !22 = !DIStringType(name: “character(*)!1”, size: 32, stringLength: !23, stringLengthExpression: !DIExpression()) !23 = !DILocalVariable(scope: !3, arg: 4, file: !4, type: !5, flags: DIFlagArtif...

On Mon, Nov 2, 2015 at 8:38 AM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Looking at the code in clang CGDebugInfo just passes through the width of > the type as it is described by the TypeInfo, which in turn is defined by > the Target. At the moment I do not understand why an x86_fp80 is reported > to be 128 bits wide. (Since it’s a type natively

...out the debugging information via dwarfdump, you can see that the size of the object is zero: > > <1>< 2233> DW_TAG_class_type > DW_AT_sibling <2295> > DW_AT_name tart.core.Object > DW_AT_byte_size 0 > DW_AT_decl_file 65 > DW_AT_decl_line 9 > <2>< 2258> DW_TAG_member > DW_AT_name __tib > DW_AT_type <2228> >...

...he debugging information via dwarfdump, you can > see that the size of the object is zero: > > <1>< 2233> DW_TAG_class_type > DW_AT_sibling <2295> > DW_AT_name tart.core.Object > * DW_AT_byte_size 0* > DW_AT_decl_file 65 > DW_AT_decl_line 9 > <2>< 2258> DW_TAG_member > DW_AT_name __tib > DW_AT_type <2228> >...

...us)               DW_AT_name        ("mod1.cpp")​ 0x000000ae:   DW_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      ...