Displaying 20 results from an estimated 20 matches for "at_nam".
Did you mean:
at_name
2015 Jan 19
2
[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
...: 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_list( 0x00000000 )
> AT_comp_dir( "/llvm_cmake" )
> AT_low_pc( 0x0000000000000000 )
> AT_high_pc( 0x00000184 )
>
> 0x0000002a: TAG_subprogram [2] *
>...
2015 Jan 19
2
[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
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
2015 Jan 19
2
[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
...b 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_list( 0x00000000 )
>> AT_comp_dir( "/llvm_cmake" )
>> AT_low_pc( 0x0000000000000000 )
>> AT_high_pc( 0x00000184 )
>>
>> 0x0000002a: TAG_s...
2015 Jan 20
2
[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
...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_list( 0x00000000 )
AT_comp_dir( "/llvm_cmake" )
AT_low_pc( 0x0000000000000000 )
AT_high_pc( 0x00000184 )
0x0000002a: TAG_subprogram [2] *
AT_low_pc( 0x000000000...
2011 Dec 29
2
[LLVMdev] DW_AT_location not getting generated for local variables
...000000: 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( 0x0000000000000000 )
AT_stmt_list( 0x00000000 )
0x00000038: TAG_namespace [2] *
AT_sibling( {0x0000005c} )
AT_name( "__main__" )
AT_decl_file(
"/Users/joe/Documents...
2011 Apr 07
1
[LLVMdev] More DWARF problems
On Apr 7, 2011, at 12:14 PM, Talin wrote:
>
> OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v:
>
> 0x000000c7: TAG_subprogram [3]
> 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" )
> 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = "tart.reflect.Parameter.construct(tart.core.String)" )
> 0x000000d0: AT_decl_file( 0x3d ( "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.t...
2012 Jan 02
0
[LLVMdev] DW_AT_location not getting generated for local variables
...= 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( 0x0000000000000000 )
> AT_stmt_list( 0x00000000 )
>
> 0x00000038: TAG_namespace [2] *
> AT_sibling( {0x0000005c} )
> AT_name( "__main__" )
> AT_dec...
2011 Oct 13
1
[LLVMdev] Local variable information in scope
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
2011 Apr 30
2
[LLVMdev] DWARF not being generated for local variable, though MD looks right(?)
...--------
.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( 0x00000000 )
AT_comp_dir( "/Users/mmp/foo" )
AT_APPLE_optimized( 0x01 )
AT_APPLE_flags( "-g" )
0x00000039: TAG_subprogram [2]...
2014 Jun 02
2
[LLVMdev] [lldb-dev] MCJIT Mach-O JIT debugging
...> 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 )
> AT_comp_dir( "." )
> AT_APPLE_optimized( 0x01 )
> AT_low_pc( 0x0000000112f5f1c0 )
> AT_high_pc( 0x000006fb )
>
> 0x0000002b: TAG_subprogram [...
2011 Apr 07
0
[LLVMdev] More DWARF problems
...>> debugger and see why it is not reaching to DwarfDebug::emitDIE().
>>
>
> OK I've been checking this out some more, and the DIEs don't look valid to
> me. Take a look at this output from dwarfdump -v:
>
> 0x000000c7: TAG_subprogram [3]
> 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" )
> 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] =
> "tart.reflect.Parameter.construct(tart.core.String)" )
> 0x000000d0: AT_decl_file( 0x3d (
> "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/P...
2011 Apr 03
2
[LLVMdev] More DWARF problems
...83 and set appropriate breakpoint in
> debugger and see why it is not reaching to DwarfDebug::emitDIE().
>
OK I've been checking this out some more, and the DIEs don't look valid to
me. Take a look at this output from dwarfdump -v:
0x000000c7: TAG_subprogram [3]
0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" )
0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] =
"tart.reflect.Parameter.construct(tart.core.String)" )
0x000000d0: AT_decl_file( 0x3d (
"/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart"...
2015 Aug 05
2
[LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
...ns have
>>>> 'Addend' in the entry, but there's no 'Addend' info in bpf elf
>>>> file(64bit). I think there must be something wrong in the process
>>>> of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the
>>>> AT_name now, DW_AT_LOCATION still missed and need your help.
>>>
Another thing about DW_AT_name, we've already found that the name
string is stored indirectly and needs relocation which is
architecture specific, while the e_machine info in bpf obj file
is "unknown", both objdump an...
2014 Jun 02
2
[LLVMdev] [lldb-dev] MCJIT Mach-O JIT debugging
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
2011 May 02
0
[LLVMdev] DWARF not being generated for local variable, though MD looks right(?)
...gt;
> 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( 0x00000000 )
> AT_comp_dir( "/Users/mmp/foo" )
> AT_APPLE_optimized( 0x01 )
> AT_APPLE_flags( "-g" )
>
> 0x00000039: TAG_...
2014 May 07
2
[LLVMdev] DWARF unmangled subprog name (DW_AT_name)
...gt;
> >>>> wrote:
> >>>> > Hi,
> >>>> >
> >>>> > I am looking for a way to get unmangled subprogram names from a
> >>>> > DWARFContext. The name I want is available in the attribute
> >>>> > `DW_AT_name`
> >>>> > [1], but as far as I can tell this is only returned as a fallback in
> >>>> > `DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage
> name
> >>>> > is not
> >>>> > available [2].
> >>>> &...
2014 May 07
5
[LLVMdev] DWARF unmangled subprog name (DW_AT_name)
...er at college.harvard.edu>wrote:
> The use case for this is in Julia backtraces. We don't have a consistent
> way to mangle the function names for linkage (we might at some point in the
> future, but this is out of scope for now). Instead, we save whatever we
> want displayed in AT_name, but there's no way to access that with the
> public API (it works nicely in gdb/lldb though).
>
Alright, I see why it makes sense. We can pass this information through
DILineInfoSpecifier. In fact, probably it makes sense to change the layout
of this structure:
there would be 3 types o...
2011 Mar 30
0
[LLVMdev] More DWARF problems
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
2011 Mar 30
5
[LLVMdev] More DWARF problems
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
2017 Feb 04
2
DWARF: Should type units be referenced by signature or declaration?
...help
address pool issue too: even if a type uses an address, it would go in the
CU but types referencing that type could still remain in a TU.
So, barring anything else, I'm sort of inclined to just make all references
to types in type units plain declarations (oh, also, DW_AT_declaration +
DW_AT_name is smaller than DW_AT_declaration + DW_AT_signature (4 bytes
instead of 8)). Simpler implementation, possible performance loss for the
debugger (lacking the shortcut to find a type by signature instead of name
lookup) and should tidy up a bunch of oddities as well as paving the way
for improvement...