search for: dw_at_frame_base

...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*) DW_ AT_external [DW_FORM_flag_present] (true) In the origin...

On Wed, Aug 27, 2014 at 4:53 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Aug 27, 2014 at 4:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> DW_AT_frame_base (the location of the frame pointer - is that needed for >> symbolication?) > > > I think this is used by libunwind style stack unwinders in conjunction > with -fomit-frame-pointer > Sounds plausible - any way I might test such a thing? - David -------------- next part -------...

...g info. I'm wondering if I'm right about what's needed for backtracing. I've removed uninteresting things, like DW_AT_accessibility (which is a bug anyway), DW_AT_external (there's no reason symbolication needs that, is there?), but also less obviously uninteresting things like DW_AT_frame_base (the location of the frame pointer - is that needed for symbolication?) Also I've made a frontend (for now) change (see mgmlt_clang.diff) to omit the data that causes DW_AT_decl_file/DW_AT_decl_line to be emitted - are those needed? I don't think so. But importantly: the only DW_TAG_subpr...

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

...# 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 # DW_AT_type .byte 2...

...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> DW_AT_prototyped : 1 <bc> DW_AT_type : <0x3f> <c...

...nes 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 (true) I suspect this is a problem with the DWARF i...

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; > <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): clang > > version 8.0.1 > > <35> DW_AT_decl_file : 1 > > <36> DW_AT_decl_line : 51 > > <37> DW_AT_type...

...m right about what's needed for backtracing. >> >> I've removed uninteresting things, like DW_AT_accessibility (which is a >> bug anyway), DW_AT_external (there's no reason symbolication needs that, is >> there?), but also less obviously uninteresting things like DW_AT_frame_base >> (the location of the frame pointer - is that needed for symbolication?) >> > > We don't use DW_AT_accessibility and DW_AT_external. > Great > As Chandler suggests, DW_AT_frame_base might be required for unwinders, > but I don't really know that. > > &...

...: (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): clang version 8.0.1 <35> DW_AT_decl_file : 1 <36> DW_AT_decl_line : 51 <37> DW_AT_type : <0x66> <3b> DW_AT_external...

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

...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 (true) >&...

...se explain use case. d) Debug info must point to the sections, not to labels inside these sections. e) Sections itself must be enclosed into braces > “.section .debug_info {…}” Again, why is this a limitation? >>>> i) .debug_frame section is emitted by txas compiler. > DW_AT_frame_base must be set to dwarf::DW_FORM_data1 > dwarf::DW_OP_call_frame_cfa value. I doubt that's a problem. Why is this a problem? On Tue, Nov 7, 2017 at 1:33 AM, Alexey Bataev via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: 06.11.2017 14:56, Robins...

...n conclude that SP + 16 = FP - 40 + 16 = FP -24 is the desired address. Here "16" is the offset obtained from debug info. So I guess there is something incompatible between our compiler backend and debug info generator. Here is my questions: 1. How can we specify which register should be DW_AT_frame_base? 2. How can we adjust the offset in DW_AT_location for variables? Best regards. 2014-02-20 3:03 GMT+08:00 Greg Clayton <gclayton at apple.com>: > If I had to guess, I would venture to say your problem is one of: > 1 - you don't have your registers correctly defined and didn'...

...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): clang >> > > version 8.0.1 >> > > <35> DW_AT_decl_file : 1 >> > > <36> DW_AT_decl_line : 51 >>...

...ith > the fact that LLVM attaches locations to instructions, not labels. It > might or might not be easy to work around this; there might be an > unfortunate interaction with how emitting line-0 records works. > >> i) .debug_frame section is emitted by txas compiler. >>     DW_AT_frame_base must be set to dwarf::DW_FORM_data1 >> dwarf::DW_OP_call_frame_cfa value. > I doubt that's a problem. > >> j) Strings cannot be referenced by the labels, instead they must be >> inlined in the sections in form of array of chars. > LLVM used to do inline strings, but s...

...l. DWARF standard does support this attribute, but it can be appiled to pointer/reference types only, not variables. h) The first label in the function must follow the debug location macro. In LLVM, it is followed by the debug location macro. i) .debug_frame section is emitted by txas compiler. DW_AT_frame_base must be set to dwarf::DW_FORM_data1 dwarf::DW_OP_call_frame_cfa value. j) Strings cannot be referenced by the labels, instead they must be inlined in the sections in form of array of chars. Some changes in LLVM are required to support all these limitation/features in the output PTX files. Require...

...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) >> >&gt...

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