similar to: [LLVMdev] llvm-dwarfdump improvements

Hi I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on some shared libraries, I see I can print the debug info (assuming it exists). For some function, I'm wondering if there's a short cut to prettyprinting the signature of a function in the library? I think, looking at the output, that enough information exists but it seems to involve looking at the subprogram

See my earlier response to Adrian. But I'll rehash the point here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional machinery required to wrap the two interfaces, so we could move the DIContext class at that time. Does

> On Jan 29, 2015, at 11:08 AM, Zachary Turner <zturner at google.com> wrote: > > See my earlier response to Adrian. But I'll rehash the point here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional

Hi, [ I Cc'd lld people and debug info people. Apologies if I omitted some stakeholder. ] As stated in the subject, I’d like to start working on an in-tree reimplementation of Darwin’s dsymutil utility. This is an initial step on the path to having lld handle the debug information itself. For those who are not familiar with the debug flow on MacOS, dsymutil is a DWARF linker. Darwin’s

> On Jan 29, 2015, at 10:20 AM, Zachary Turner <zturner at google.com> wrote: > > I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. > > There's still more to be done on the pdb dumping tool, but at this

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

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

> 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

Hi Frédéric and LLVM, I managed to finally come back to this after quite a while. Frédéric, thank you very much for the pointer to your work; it’s saving me a lot of time! Unfortunately, I am running into one issue that my knowledge isn’t complete enough to solve on my own yet. The description of D6771 reads, "It requires a few preliminary patches like landing D6243 and adding a

(oops, switch mailing list) On Tue, Nov 17, 2015 at 4:07 PM, David Blaikie <dblaikie at gmail.com> wrote: > Wee, delayed response, but nothing drastic: > > I just noticed the tool is "llvm-dsymutil" but it's in tools/dsymutil, > unlike all the other tools that have the llvm-prefix in the directory name. > Could we move it to "tools/llvm-dsymutil" for

I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. There's still more to be done on the pdb dumping tool, but at this point -- to reduce duplicated effort -- I think it makes the most sense to start moving some of this logic

In ELF .o files with debug info, there are relocations applied to the DWARF sections. For example, when emitting offsets into the stringpool, we emit a relocation. How should we support this? llvm-dwarfdump currently works by finding the relevant dwarf sections and passing them in to lib/DebugInfo. The relocations can be iterated over in lib/Object using the relocation_iterator. Should dwarfdump

Hi, This is my first post to this list, so I apologize in advance if I mess up on any list etiquette. Jumping right in, I’m making use of the DebugInfo/DWARF APIs to get debugging information out of binaries (what else!). One of the bits of data I need is the location information stored in the location list section as well as inline in DW_AT_location attributes and similar. So far I’ve succeeded

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. However, I'm also seeing a lot of new problems which weren't exposed before. After spending the better part of two

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

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 Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > > After to speaking to Devang and a number of other people at the developer's > conference, I was able to make some forward progress on getting debugging to > work. I'm now able to actually single-step through my program and set > breakpoints,

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML