similar to: [LLVMdev] Dropping the DW_ prefix from names in dwarfdump

> On Jan 19, 2015, at 10:26 AM, Adrian Prantl <aprantl at apple.com> wrote: > > >> On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Hey guys, >> >> Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every

> On Jan 19, 2015, at 10:34 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Jan 19, 2015 at 10:29 AM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Jan 19, 2015, at 10:26 AM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: >> >> >>> On Jan

Hear hear. DW_ adds no readability but AT_/TAG_/OP_/etc do. Dropping the FORM entirely is fine; I view that as a mechanical encoding thing, not relevant to the informational content. If you're debugging the encoding then it would matter, but for a random string-value attribute it really doesn't matter which of the 3 (4?) different forms was used as long as the actual string shows up

I figured out my previous problem with DIBuilder. However, now I can't seem to get the compiler to emit location information for local variables. Here's how my IR looks: --- define i32 @"\01_main"() { init: %exception1 = alloca i8* %0 = alloca i32 %"bar:Int32" = alloca i32 %1 = alloca i32 %2 = alloca i32* br label %code code:

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

I found the problem. The llvm.dbg.declare call must have a !dbg tag, otherwise the location info is not generated. Changing the invocation in my original example to "call void @llvm.dbg.declare(metadata !{i32* %"bar:Int32"}, metadata !13), !dbg !16" causes MC to generate the local location as expected. -Joe On Thu, Dec 29, 2011 at 12:41 PM, Joe Groff <arcata at

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] =

On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > 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:

On Sat, Apr 2, 2011 at 11:03 PM, Talin <viridia at gmail.com> wrote: > > > On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> 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

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

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

We don't currently apply any relocations (that I know of) for 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 =

I think I get it now, thanks for explaining! >> On Jan 12, 2020, at 11:44 AM, David Blaikie via llvm-dev <llvm-dev at lists.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

Bunch of initially unrelated context: * type units can be referenced in a variety of ways: * DW_FORM_ref_sig8 on any attribute needing to reference the type * DW_AT_signature on a declaration of the type * extra wrinkle: the declaration can be nested into the appropriate namespace and given a name, or not * LLVM always does the "most expressive"/expensive thing: a full

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

I'm running into a problem with generating debugging information that I'm not sure how to debug; I'd be happy to have some suggestions about where to start digging in. In short, I believe that I'm correctly generating debug info (with DIBuilder, which has so far been quite nice!), and a scan of the meta-data in the IR looks generally right. However, if I run dwarfdump on my

Hi, Alexei On 2015/7/30 1:13, Alexei Starovoitov wrote: > On 7/29/15 2:38 AM, He Kuang wrote: >> Hi, Alexei >> >> On 2015/7/28 10:18, Alexei Starovoitov wrote: >>> On 7/25/15 3:04 AM, He Kuang wrote: >>>> I noticed that for 64-bit elf format, the reloc sections have >>>> 'Addend' in the entry, but there's no 'Addend' info

https://bugzilla.mindrot.org/show_bug.cgi?id=1420 Summary: BSM support on Mac OS X Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: bitbucket at mindrot.org

Hi, [ I think I put the most important contributors to the DebugInfo stuff in Cc:. Is there anyone else that I am missing? ] Just a short notice that I am currently working on making llvm-dwarfdump more developer friendly. There are quite a few features in Darwin’s dwarfdump that we find quite useful and that we would like to contribute to llvm-dwarfdump. I have started by augmenting the