search for: at_low_pc

..._producer( "clang 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...

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

...ng 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 ) >>...

...unit [1] * AT_producer( "clang 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" )...

...NULL 0x0000005c: TAG_base_type [4] 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_...

...ists.llvm.org> wrote: >  > > >> On Fri, Jan 10, 2020 at 12:57 PM Vedant Kumar <vedant_kumar at apple.com> wrote: >> 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)', > > With Split DWARF or with DWARFv5 in LLVM at the moment, all addresses are indirected already. So it's: > > Replace "A...

...type [4] >                  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 ) > &gt...

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 the offset out? thanks, vedant > On Ja...

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

...t; AT_producer( "julia" ) > 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_link...

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

...AT_decl_file( 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 0x00000...

...)" ) 0x000000d0: AT_decl_file( 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_uni...

...t; then > offset_pairs (an improvement over similar functionality in DWARFv4 because > the offset pairs can be uleb encoded - so they can be quite compact)) > > > > But one place that DWARFv5 misses to reduce relocations further is > direct addresses from debug_info, such as DW_AT_low_pc. > > > > For a while I've wondered if we could use an extension form for > addr+offset, and I prototyped this without an extension attribute, but > instead using exprloc. This has slightly higher overhead to express the... > expression. (it's 9 bytes in total, could be...

...: AT_decl_file( 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...

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

...B files and use 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 par...