similar to: [LLVMdev] Next round of DWARF issues/questions

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, and examine function parameters. > > However, I'm also seeing a lot of new problems which

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,

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

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

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:

I've been struggling with this for a while. I've gone back and reviewed all the messages in this topic on the subject, and I still can't figure it out. -- I'm disabling frame pointer elimination via "-disable-fp-elim" -- I see debugging information in my .s file. -- My command line for compiling the LLVM-generated looks like this: gcc -g -O0 -x assembler

On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > > On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: > >> I recently started getting this error when I try to debug my LLVM-compiled >> program in GDB: >> >> Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c >> [in module

I recently started getting this error when I try to debug my LLVM-compiled program in GDB: Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c [in module /home/talin/Projects/tart/build-eclipse/test/stdlib/ReflectionTest] I'm not sure if it's something I did or not. Is there any way to track down the cause of this error? The hex addresses in the error message are

On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > >> >> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >> >>> I recently started getting this error when I try to debug my >>> LLVM-compiled program in GDB:

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]"*

Hi All, Was looking into a simple program - class Simple { public: void fun() {} }; int main() { Simple s; s.fun(); return 0; } When compiled using clang++ for ARM- Expected result when we run - print Simple::fun in GDB is void fun(Simple* const this) as this should be a const pointer but in case of arm compiled binary we get void fun(Simple* this). Works fine when compiled using

> warning: Could not find object file > "/var/folders/h6/h6He5G34EF8g9zpg3SNFF++++TI/-Tmp-//ccoTexQw.o" - no debug > information available for "ReflectionTest.tart". It seems you're on darwin, right? Then you need another build steps in order to see dwarf stuff -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State

Hi Karthik, > Expected result when we run - > > print Simple::fun in GDB is > void fun(Simple* const this) > > as this should be a const pointer but in case of arm compiled binary we get > void fun(Simple* this). I believe the actual type is coming from CXXMethodDecl::getThisType, which quotes the standard as saying: // C++ 9.3.2p1: The type of this in a member function

On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: > I recently started getting this error when I try to debug my LLVM-compiled > program in GDB: > > Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c > [in module > /home/talin/Projects/tart/build-eclipse/test/stdlib/ReflectionTest] > > I'm not sure if it's something

Hi debug-info folks, I've recently been experimenting with the -debug-info-kind=constructor model for debug-info creation, which is leading to some significant reductions in .debug_info on our large C++ benchmarks, which is great! I see in PR46537 that there's a plan to eventually enable this by default -- is this something we can target for LLVM12, or are there outstanding issues? While

I'm attempting to get my compiler to use the new APIs for source-level debugging via SetCurrentDebugLocation(). I'm getting a lot of "duplicate symbol" errors in my generated assembly code: ReflectionTest.s:348: Error: symbol `.Lfunc_end6' is already defined ReflectionTest.s:372: Error: symbol `.Lfunc_end6' is already defined ReflectionTest.s:395: Error: symbol

Talin wrote: > I'm attempting to get my compiler to use the new APIs for source-level > debugging via SetCurrentDebugLocation(). I'm getting a lot of "duplicate > symbol" errors in my generated assembly code: > > ReflectionTest.s:348: Error: symbol `.Lfunc_end6' is already defined > ReflectionTest.s:372: Error: symbol `.Lfunc_end6' is already defined

On Sun, Nov 29, 2009 at 9:12 AM, Talin <viridia at gmail.com> wrote: > Talin wrote: >> I'm attempting to get my compiler to use the new APIs for source-level >> debugging via SetCurrentDebugLocation(). I'm getting a lot of "duplicate >> symbol" errors in my generated assembly code: >> >> ReflectionTest.s:348: Error: symbol `.Lfunc_end6'

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 Aug 31, 2010, at 9:03 AM, Talin wrote: > 4) What is the meaning of the "inlinedAt" argument for DebugLoc::get()? Does it mean the location where the inlined code was defined, or the location where it was expanded? the location where it was expanded - Devang