search for: abbr_offset

...lt settings > > ---------------------------------------------------------------------- > File: out.o (x86_64) > ---------------------------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "clang version 3.5.0 (209308)" ) > AT_language( DW_LANG_C_plus_plus ) > AT_name( "test.cc <http://test.cc/>"...

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

...t; ---------------------------------------------------------------------- >> File: out.o (x86_64) >> ---------------------------------------------------------------------- >> .debug_info contents: >> >> 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) >> >> 0x0000000b: TAG_compile_unit [1] * >> AT_producer( "clang version 3.5.0 (209308)" ) >> AT_language( DW_LANG_C_plus_plus ) >> AT_name( "test.cc <http:...

...base_type [24] DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000051] = "int") DW_AT_encoding [DW_FORM_data1] (0x05) DW_AT_byte_size [DW_FORM_data1] (0x04) 0x00000058: NULL 0x000001ec: Compile Unit: length = 0x0000002b version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0000021b) 0x0000000b: DW_TAG_type_unit [25] * DW_AT_language [DW_FORM_data2] (0x0004) 0x0000000e: DW_TAG_namespace [9] * It is a bit weird using the same syntax to print the section relative offest for the unit header, then unit-relati...

...9;s dwarfdump output with the default settings ---------------------------------------------------------------------- File: out.o (x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x0000005f) 0x0000000b: TAG_compile_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_li...

...other thing is to build a couple of indexing data structures to allow fast lookup of CUs and TUs. Likely I'll start with: * adding llvm-dwarfdump support for the DWP indexes * basic prototype of llvm-dwp just concatenating sections * handle each of the domain specific relocations in turn * abbr_offset * debug_str_offsets.dwo entries * type_unit's DW_AT_stmt_list * references to debug_loc.dwo from debug_info.dwo * this one, at first blush, makes me particularly sad, as it'll involve actually walking all the DIEs in any CUs (stmt_list isn't great either, but at least that...

...to allow fast lookup of CUs and TUs. >> >> Likely I'll start with: >> >> * adding llvm-dwarfdump support for the DWP indexes >> * basic prototype of llvm-dwp just concatenating sections >> * handle each of the domain specific relocations in turn >> * abbr_offset >> * debug_str_offsets.dwo entries >> * type_unit's DW_AT_stmt_list >> * references to debug_loc.dwo from debug_info.dwo >> * this one, at first blush, makes me particularly sad, as it'll >> involve actually walking all the DIEs in any CUs (stmt_list...

...ed would be greatly appreciated! Thanks, -matt ---------------------------------------------------------------------- File: a.o (x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x00000043 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000047) 0x0000000b: TAG_compile_unit [1] * AT_producer( "volta" ) AT_language( DW_LANG_C99 ) AT_name( "a.c" ) AT_entry_pc( 0x0000000000000000 ) AT_stmt_list( 0x00000...

...'bar' is missing its AT_location. --- ---------------------------------------------------------------------- File: foo.o (x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x000000a9 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x000000ad) 0x0000000b: TAG_compile_unit [1] * AT_producer( "clay compiler 0.1git" ) AT_language( Unknown DW_LANG constant: 0xc1a4 ) AT_name( "foo.clay" ) AT_entry_pc( 0x000000000000...

...or debug info in LLDB. > On Jun 2, 2014, at 12:35 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > > I think I'm getting closer. The debug_info section is being relocated correctly (I think): > > 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000049) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "julia" ) > AT_language( DW_LANG_C89 ) > AT_name( "string.jl" ) > AT_stmt_list( 0x00000000 ) >...

...ion. > > --- > ---------------------------------------------------------------------- >  File: foo.o (x86_64) > ---------------------------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x000000a9  version = 0x0002  abbr_offset > = 0x00000000  addr_size = 0x08  (next CU at 0x000000ad) > > 0x0000000b: TAG_compile_unit [1] * >              AT_producer( "clay compiler 0.1git" ) >              AT_language( Unknown DW_LANG constant: 0xc1a4 ) >              AT_name( "foo.clay" ) >      ...

Hi all, I've put this email in a different thread, although it is quite similar to some of the threads on tombstoning etc, with similar underlying structural issues. Whilst prototyping my fragmented DWARF idea for GC-ing DWARF sections properly, I ran into an object in the game code I was using as my input where a v4 .debug_loc section had a location description that looked something like

...000d6: 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_str[0x00000001] = "0.1 tartc" ) > 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) > 0x000000f4: AT_name( .debug_str[0x000001fa] = "range....

...000066 => {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_str[0x00000001] = "0.1 tartc" ) 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) 0x000000f4: AT_name( .debug_str[0x000001fa] = "range.tart" ) 0x000000f8:...

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

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

...t; -matt > > > ---------------------------------------------------------------------- > File: a.o (x86_64) > ---------------------------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x00000043 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000047) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "volta" ) > AT_language( DW_LANG_C99 ) > AT_name( "a.c" ) > AT_entry_pc( 0x0000000000000000 ) >...

...000000d6: 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_str[0x00000001] = "0.1 tartc" ) > 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) > 0x000000f4: AT_name( .debug_str[0x000001fa] = "range...

Dear LLVM devs, I've noticed that LLVM's assembler (and hence clang) doesn't generate debug data when assembling, even when run with "-g". Users can add their own CFI/line number data with assembler directives. But GDB ignores the line number data if you don't have a DIE in the .debug_info section which identifies the compilation unit. (I'm not an expert on GDB, but

...DW_CHILDREN_no > DW_AT_name DW_FORM_strp > DW_AT_encoding DW_FORM_data1 > DW_AT_byte_size DW_FORM_data1 > > [6] DW_TAG_pointer_type DW_CHILDREN_no > DW_AT_type DW_FORM_ref4 > > > .debug_info contents: > 0x00000000: Compile Unit: length = 0x00000094 version = 0x0002 abbr_offset > = 0x0000 addr_size = 0x04 (next CU at 0x00000098) > > 0x0000000b: DW_TAG_compile_unit [1] * > 0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] = > "clang version 3.3 (/opt/git.repo/clang.git/ > b422d20530588813b09057b45d5b383f0b175ced) (/opt/git.repo/llv...