similar to: [LLVMdev] New debugging APIs

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'

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

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

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:

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

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

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

> 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

Hmmm that is a funny sequence. I know the .cfi directives are represented as pseudo-instructions, but they should not be causing us to emit .loc directives. They have no effect on the .text section so probably they should just be excluded from emitting a location, same as DBG_VALUE is excluded. Also I believe the label there is unnecessary, but that's a separate issue. Regarding "how

(2) cause CFI instructions not to emit any .loc directives; done in r289256, plus r289288 (3) file a bug to have someone audit LoopVectorizer.cpp to see whether it is using SetCurrentDebugLocation in the right places; haven't done that part yet (4) reapply my "line 0" patch, which will be the 3rd attempt. r289468 Please ping me when you do (4). Also, will there be a flag to disable

On Fri, Dec 2, 2016 at 5:42 PM, Robinson, Paul <paul.robinson at sony.com> wrote: > I've determined that the "pesky" .loc is indeed because of the .cfi > directive that comes immediately after it. Some of the CFI instructions > have source locations, some don't. But, emitting a source location for a > CFI instruction is inappropriate. It's easy enough to

On Sat, Aug 28, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > 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

There is already –mllvm –use-unknown-locations which ought to trigger this. Don't need my patch. --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 4:08 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Libfuzzer depending on uninitialized debug info On Thu, Dec 1, 2016 at 3:37 PM, Robinson, Paul <paul.robinson at

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

Hello, For some reason, I have to stick on llvm 3.3 for a language compiler, I find that the location debug info is attached to each instruction using !dbg, however, I found some of that information is mis-attched and need to be changed, so I want to *know what functions(I checked all funcs in DIBuilder.h but didn't find a appropriate one) are used to attach those !dbg nodes to each