search for: dw_at_high_pc

I think we have to be careful here. We might want flexibility to say "I want to use a specific class" without having to specify the exact DW_FORM. Sometimes, we might even end up in an ambiguous situation and not get the result we want. For example, in DWARFv4, the DW_AT_high_pc attribute has either a Constant or an Address class, which use completely different forms, but if we have just "Value: 0x1234", which is it? In DWARFv3, it is always an Address, if I remember correctly, so in that case, we might want our default to be "Address". However, for DWA...

...# DW_AT_name .byte 0 .byte 1 # DW_AT_decl_file .byte 12 # DW_AT_decl_line .byte 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...

...RM_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 [DW_FORM_strp] ( .debug_str[0x00001616] = "FB_FPUMP at HORIZONTAL") DW_AT_type [DW_FORM_ref_addr] (*0x000000006e440296*)...

...(indirect string, offset: 0x0): clang > > version 8.0.1 > > <16> DW_AT_stmt_list : 0x0 > > <1a> DW_AT_comp_dir : (indirect string, offset: 0x0): clang > > version 8.0.1 > > <1e> DW_AT_low_pc : 0x0 > > <22> DW_AT_high_pc : 0x6c > > <1><26>: Abbrev Number: 2 (DW_TAG_subprogram) > > <27> DW_AT_low_pc : 0x0 > > <2b> DW_AT_high_pc : 0x6c > > <2f> DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1 (r1)) > > <31>...

...: 12 (ANSI C99) <12> DW_AT_name : (indirect string, offset: 0x0): clang version 8.0.1 <16> DW_AT_stmt_list : 0x0 <1a> DW_AT_comp_dir : (indirect string, offset: 0x0): clang version 8.0.1 <1e> DW_AT_low_pc : 0x0 <22> DW_AT_high_pc : 0x6c <1><26>: Abbrev Number: 2 (DW_TAG_subprogram) <27> DW_AT_low_pc : 0x0 <2b> DW_AT_high_pc : 0x6c <2f> DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1 (r1)) <31> DW_AT_name : (indirect string, offset: 0x0...

...;, scope: !1, file: !2, unit: !1) Why? When two functions share the same DISubprogram attachment, the DWARF backend gets very confused and adds all attributes from all functions to the same subprogram DIE, so we end up with something looking like: DW_TAG_subprogram DW_AT_low_pc // f1 DW_AT_high_pc DW_AT_low_pc // f2 DW_AT_high_pc ... etc. Seeing this it seemed obvious to me we should disallow this by preventing two functions from sharing the same !dbg attachment. After implementing my new verifier check (and updating a couple of hand-crafted testcases that violated it) I noti...

...t; version 8.0.1 >> > > <16> DW_AT_stmt_list : 0x0 >> > > <1a> DW_AT_comp_dir : (indirect string, offset: 0x0): clang >> > > version 8.0.1 >> > > <1e> DW_AT_low_pc : 0x0 >> > > <22> DW_AT_high_pc : 0x6c >> > > <1><26>: Abbrev Number: 2 (DW_TAG_subprogram) >> > > <27> DW_AT_low_pc : 0x0 >> > > <2b> DW_AT_high_pc : 0x6c >> > > <2f> DW_AT_frame_base : 1 byte block: 51 (DW_OP_r...

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

...# DW_AT_decl_line > # DW_AT_prototyped > .int 127 # DW_AT_type > # 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...

...be valid for the lifetime of the variable, contrary to when the variable is actually defined(or allocated) which is in this case Line No. 7. --------------------------------------------- 0x0000006d: DW_TAG_lexical_block DW_AT_low_pc (0x00000000002016d1) DW_AT_high_pc (0x000000000020170b) 0x0000007a: DW_TAG_variable DW_AT_location (DW_OP_fbreg -24) DW_AT_name ("Local") DW_AT_decl_file ("MainScope.c") DW_AT_decl_line (7) DW_...

...rk pretty well, and the DWARF looked legit: ``` 0x0000005f: DW_TAG_variable DW_AT_location (DW_OP_fbreg -20) DW_AT_name ("Local") 0x0000006d: DW_TAG_lexical_block DW_AT_low_pc (0x0000000100000f4f) DW_AT_high_pc (0x0000000100000f84) 0x0000007a: DW_TAG_variable DW_AT_location (0x00000000 [0x0000000100000f63, 0x0000000100000f8c): DW_OP_breg6 RBP-24) DW_AT_name ("Local”) ``` I did find one lldb bug where it didn’t know to look...

...ttached file with: $ clang -O1 -g test.c -lpthread If I run: $ readelf --debug-dump=info ./a.out I see the following debugging information in the binary for "main": <1><a7>: Abbrev Number: 7 (DW_TAG_subprogram) <a8> DW_AT_low_pc : 0x400880 <b0> DW_AT_high_pc : 0xc9 <b4> Unknown AT value: 3fe7: 1 <b4> DW_AT_frame_base : 1 byte block: 57 (DW_OP_reg7 (rsp)) <b6> DW_AT_name : (indirect string, offset: 0xaf): main <ba> DW_AT_decl_file : 1 <bb> DW_AT_decl_line : 16 <bc...

...think you're right, but for my case, regrettably, not. Because my target is a Harvard Architecture, any code address can have the same ordinal value as any data address: the code and data reside on different buses so the whole 4GiB space is available to both code, and data. `DW_AT_low_pc` and `DW_AT_high_pc` can be used to find the range of the code segment, but given an arbitrary address, cannot be used to conclusively determine whether that address belongs to code or data when both segments contain addresses in that numeric range. All the Best Luke -- Codeplay Software Ltd. Company registered in...

...0040] 0.000089 <invalid>:0:0: fqux ... 4 lines omitted If I then inspect the executable with 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...

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

...se, AttributeSpecs = llvm::SmallVector of length 8, capacity 8 = {{ Attr = llvm::dwarf::Attribute::DW_AT_low_pc, Form = llvm::dwarf::Form::DW_FORM_addr, ByteSize = llvm::Optional is not initialized }, { Attr = llvm::dwarf::Attribute::DW_AT_high_pc, Form = llvm::dwarf::Form::DW_FORM_data8, ByteSize = llvm::Optional is initialized = { value = 8 '\b' } Here you can see the pretty printers for SmallVector and Optional, but there's also support for StringRef, SmallString, and ArrayRef...

...the declaration with the definition. But that problem could be more easily resolved when debug info is generated(probably without significant increase of debug info size): Let`s check the example: 0x0000000b: DW_TAG_compile_unit DW_AT_low_pc (0x0000000000201700) DW_AT_high_pc (0x0000000000201719) 0x0000002a: DW_TAG_subprogram 0x00000043: DW_TAG_inlined_subroutine DW_AT_abstract_origin (0x0000000000000086 "_Z1fv") DW_AT_low_pc (0x0000000000201700) DW_AT_high_pc (0x0000000000201718) 0x00000057:...

...s = llvm::SmallVector of length 8, capacity 8 = {{ > Attr = llvm::dwarf::Attribute::DW_AT_low_pc, > Form = llvm::dwarf::Form::DW_FORM_addr, > ByteSize = llvm::Optional is not initialized > }, { > Attr = llvm::dwarf::Attribute::DW_AT_high_pc, > Form = llvm::dwarf::Form::DW_FORM_data8, > ByteSize = llvm::Optional is initialized = { > value = 8 '\b' > } > > Here you can see the pretty printers for SmallVector and Optional, but > there's also support for St...

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

...d >> >> If I then inspect the executable with 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...