search for: dw_form_block1

...sent > .byte 17 # DW_AT_low_pc > .byte 1 # DW_FORM_addr > .byte 18 # DW_AT_high_pc > .byte 1 # DW_FORM_addr > .byte 64 # DW_AT_frame_base > .byte 10 # DW_FORM_block1 > .byte 0 # EOM(1) > .byte 0 # EOM(2) > .byte 3 # Abbreviation Code > .byte 5 # DW_TAG_formal_parameter > .byte 0 # DW_CHILDREN_no > .byte 3 # DW_...

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

...# DW_FORM_flag .byte 58 # DW_AT_decl_file .byte 11 # DW_FORM_data1 .byte 59 # DW_AT_decl_line .byte 11 # DW_FORM_data1 .byte 2 # DW_AT_location .byte 10 # DW_FORM_block1 .byte 0 # EOM(1) .byte 0 # EOM(2) .byte 4 # Abbreviation Code .byte 46 # DW_TAG_subprogram .byte 1 # DW_CHILDREN_yes .byte 1 # DW_AT_sibling .byte 19...

...t; .byte 1 # DW_FORM_addr > > .byte 18 # DW_AT_high_pc > > .byte 1 # DW_FORM_addr > > .byte 64 # DW_AT_frame_base > > .byte 10 # DW_FORM_block1 > > .byte 0 # EOM(1) > > .byte 0 # EOM(2) > > .byte 3 # Abbreviation Code > > .byte 5 # DW_TAG_formal_parameter > > .byte 0...

...formal_parameter (abbrev = 27, offset = 14760) has children: FALSE attributes: DW_AT_name (DW_FORM_strp) string: "testType" DW_AT_decl_file (DW_FORM_data1) constant: 74 DW_AT_decl_line (DW_FORM_data1) constant: 47 DW_AT_type (DW_FORM_ref4) constant ref: 43711 (adjusted) DW_AT_location (DW_FORM_block1) block: size 2 Dwarf Error: Cannot find type of die [in module /Users/talin/Projects/tart/build-eclipse/test/stdlib/BitTricksTest.dSYM/Contents/Resources/DWARF/BitTricksTest] This is good because I know exactly where that parameter is - now the question is to figure out what is wrong with it. &g...

On Mar 29, 2011, at 7:29 PM, Talin wrote: > I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: > > gdb stack crawl at point of internal error: > [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin

I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: gdb stack crawl at point of internal error: [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin

...;0x01> 55 ) ^ <stdin>:1:1: note: scanning from here /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/test/CodeGen/X86/Output/dbg-merge-loc-entry.ll.tmp: file format Mach-O 64-bit x86-64 ^ <stdin>:72:31: note: possible intended match here 0x0000008c: DW_AT_frame_base [DW_FORM_block1] (<0x01> 57 ) ^ -- ******************** FAIL: LLVM :: CodeGen/X86/sub-with-overflow.ll (37 of 51) ******************** TEST 'LLVM :: CodeGen/X86/sub-with-overflow.ll' FAILED ******************** Script: -- /usr/local/google/home/blaikie/dev/llvm/build/cl...