similar to: [LLVMdev] Dwarf debugging strangeness, continued...

On Oct 20, 2010, at 10:49 PM, Talin wrote: > First, there are a bunch of .bc files that are generated by my frontend, and which contain debugging metadata (I checked using llvm-dis and the metadata appears to be OK). These are then combined by my linker, tartln, which combines the functions of 'opt' and 'llc', as well as having some custom passes for reflection and garbage

On Thu, Oct 21, 2010 at 8:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 20, 2010, at 10:49 PM, Talin wrote: > > > - First, there are a bunch of .bc files that are generated by my > frontend, and which contain debugging metadata (I checked using llvm-dis and > the metadata appears to be OK). These are then combined by my linker, > tartln,

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 31, 2011, at 12:57 AM, Talin 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 about a month now. Here's what happens when I attempt to use gdb

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 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 Thu, Mar 31, 2011 at 9:15 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 31, 2011, at 12:57 AM, Talin 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

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

>From my understanding, the LLVM classes are just representing the DWARF information without doing any extra work, so I am afraid that you will have to explicitly chase through all the DWARF information yourself. On 4/5/2018 3:22 PM, Bill O'Hara via llvm-dev wrote: > Hi > > I'm using llvm-5. Browsing the source of llvm-dwarfdump and trying it on > some shared libraries, I

On Thu, Nov 25, 2010 at 5:55 PM, Talin <viridia at gmail.com> wrote: > On Tue, Nov 9, 2010 at 9:04 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> >> On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: >> >> On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel < <dpatel at apple.com> >> dpatel at apple.com> wrote:

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

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

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 Tue, Nov 9, 2010 at 9:04 AM, Devang Patel <dpatel at apple.com> wrote: > > > On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel < <dpatel at apple.com> > dpatel at apple.com> wrote: > >> >> On Nov 6, 2010, at 7:35 PM, Talin wrote: >> >> After to speaking to Devang

Well, I am much happier now that I understand about dsymutil, and can actually step through my program in gdb. However, there are still some issues that are puzzling me. 1) First off, the debugger appears to stop at odd points. The IR for my main function looks correct to me: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"*

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

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

On Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote: > BTW, the reason I stopped responding to this thread is not because I solved > the problem, but because I simply gave up and decided to work on other > things for a while since I was making no progress. Having finished those > other things (the stack crawler, for one), I'm hoping that time and a fresh >

BTW, the reason I stopped responding to this thread is not because I solved the problem, but because I simply gave up and decided to work on other things for a while since I was making no progress. Having finished those other things (the stack crawler, for one), I'm hoping that time and a fresh start will yield better results. Unfortunately after about a day spent reviewing old llvm-dev