search for: at_high_pc

...; ) > AT_language( DW_LANG_C_plus_plus ) > AT_name( "test.cc <http://test.cc/>" ) > AT_stmt_list( 0x00000000 ) > AT_comp_dir( "/llvm_cmake" ) > AT_low_pc( 0x0000000000000000 ) > AT_high_pc( 0x00000184 ) > > 0x0000002a: TAG_subprogram [2] * > AT_low_pc( 0x0000000000000000 ) > AT_high_pc( 0x00000184 ) > AT_frame_base( rbp ) > AT_MIPS_linkage_name( "_Z3bari" ) > AT_na...

Hey guys, Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) Any thoughts on skipping the "DW_" (maybe even the AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM

...AT_language( DW_LANG_C_plus_plus ) >> AT_name( "test.cc <http://test.cc/>" ) >> AT_stmt_list( 0x00000000 ) >> AT_comp_dir( "/llvm_cmake" ) >> AT_low_pc( 0x0000000000000000 ) >> AT_high_pc( 0x00000184 ) >> >> 0x0000002a: TAG_subprogram [2] * >> AT_low_pc( 0x0000000000000000 ) >> AT_high_pc( 0x00000184 ) >> AT_frame_base( rbp ) >> AT_MIPS_linkage_name( "_Z3bari" ) &gt...

...ang version 3.5.0 (209308)" ) AT_language( DW_LANG_C_plus_plus ) AT_name( "test.cc<http://test.cc/>" ) AT_stmt_list( 0x00000000 ) AT_comp_dir( "/llvm_cmake" ) AT_low_pc( 0x0000000000000000 ) AT_high_pc( 0x00000184 ) 0x0000002a: TAG_subprogram [2] * AT_low_pc( 0x0000000000000000 ) AT_high_pc( 0x00000184 ) AT_frame_base( rbp ) AT_MIPS_linkage_name( "_Z3bari" ) AT_name( "bar" )...

...AT_name( "Int32" ) AT_encoding( DW_ATE_signed ) AT_byte_size( 0x04 ) 0x00000065: TAG_subprogram [5] * AT_specification( {0x00000048} ( "_main" ) ) AT_low_pc( 0x0000000000000020 ) AT_high_pc( 0x0000000000000051 ) AT_frame_base( rbp ) 0x0000007c: TAG_lexical_block [6] * AT_low_pc( 0x0000000000000028 ) AT_high_pc( 0x000000000000004c ) 0x0000008d: TAG_lexical_block [6] * AT_low_pc( 0x...

...ot; ) >                  AT_encoding( DW_ATE_signed ) >                  AT_byte_size( 0x04 ) > > 0x00000065:     TAG_subprogram [5] * >                  AT_specification( {0x00000048} ( "_main" ) ) >                  AT_low_pc( 0x0000000000000020 ) >                  AT_high_pc( 0x0000000000000051 ) >                  AT_frame_base( rbp ) > > 0x0000007c:         TAG_lexical_block [6] * >                      AT_low_pc( 0x0000000000000028 ) >                      AT_high_pc( 0x000000000000004c ) > > 0x0000008d:             TAG_lexical_block [6] * >...

Hi,   I want to list some additional information on this.   The variable collection I am looking at is, "variables 'declared' in scope".   1. When I traverse the MachineInstructions in the LexicalScopes ranges, and check for variables, I get variables used in this scope.      The variables listed include variables which may not have been declared in the scope. (for example

...gt; AT_language( DW_LANG_C89 ) > AT_name( "string.jl" ) > AT_stmt_list( 0x00000000 ) > AT_comp_dir( "." ) > AT_APPLE_optimized( 0x01 ) > AT_low_pc( 0x0000000112f5f1c0 ) > AT_high_pc( 0x000006fb ) > > 0x0000002b: TAG_subprogram [2] > AT_low_pc( 0x0000000112f5f1c0 ) > AT_high_pc( 0x0000000112f5f8bb ) > AT_frame_base( rbp ) > AT_MIPS_linkage_name( "julia_parseint_nocheck;18749"...

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

.../Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart" ) ) > 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) > 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} ( ) ) > 0x000000d6: AT_external( 0x01 ) > 0x000000d7: AT_low_pc( 0x0000f780 ) > 0x000000db: AT_high_pc( 0x0000f7b1 ) > 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) > > 0x000000e1: NULL > > 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 > abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) > > 0x000000ed: TAG_compile_unit [1]...

...0x3d ( "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart" ) ) 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} ( ) ) 0x000000d6: AT_external( 0x01 ) 0x000000d7: AT_low_pc( 0x0000f780 ) 0x000000db: AT_high_pc( 0x0000f7b1 ) 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) 0x000000e1: NULL 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) 0x000000ed: TAG_compile_unit [1] * 0x000000ee: AT_producer( .debug_s...

...e the pool of addresses down to, ideally, one address per section/indivisible chunk of machine code (per subsection in MachO, for instance) (whereas currently there are many addresses per section) > >> How do you figure the offset out? > > Label difference - same as is done for DW_AT_high_pc today in DWARFv4 and DWARFv5 in LLVM. high_pc currently uses the low_pc addresse to be relative to, in this proposed situation, we'd use a symbol that's in the first bit of debug info in the section (or subsection in MachO). So the low_pc of the subprogram/function, for instance, or if ther...

.../Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart" ) ) > 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) > 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} ( ) ) > 0x000000d6: AT_external( 0x01 ) > 0x000000d7: AT_low_pc( 0x0000f780 ) > 0x000000db: AT_high_pc( 0x0000f7b1 ) > 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) > > 0x000000e1: NULL > > 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) > > 0x000000ed: TAG_compile_unit [1] *...

I don't totally follow the proposed encoding change & would appreciate a small example. Is the idea to replace e.g. an 'AT_low_pc (<direct address>) + relocation for <direct address>' with an 'AT_low_pc (<indirection into a pool of addresses> + offset)', s.t. the cost of a relocation for the address is paid down the more it's used? How do you figure

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

...e it for strings stream. dbghelp: Get stream indexes out of PDB files (instead of hardwired values). dbghelp: When failing to look up for a PDB file, don't keep a module format object around. dbghelp: Use AT_range attribute (for function, block... addresses) when AT_low_pc and AT_high_pc are not present. dbghelp, winedump: Added definition for S_FRAMEPROC_V2 symbol (CodeView). kernel32: Added support for terminfo/termcap in console code. kernel32: Move the input character to INPUT_RECORD translation functions to term.c. kernel32: Correctly parse the input st...