similar to: [LLVMdev] DWARF not being generated for local variable, though MD looks right(?)

On Apr 29, 2011, at 5:49 PM, Matt Pharr wrote: > 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

> 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

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 =

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

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:

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:

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

Hey guys, Frederic is introducing the expression dumping support and in the interests of tersity is skipping the "DW_" in every "DW_OP" (heck, we could even skip the "OP" given the context - nothing else textual can appear there, right?) Any thoughts on skipping the "DW_" (maybe even the AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM

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

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

hi Jean-Marc, I just updated from svn and it looks like there are some errors in the speex.mmp file. the filters.c is duplicated, and the fft/kiss.c files are still missing.. /alfred Jean-Marc Valin wrote: > Applied in svn. Thanks. > > Jean-Marc > > Alfred E. Heggestad a ?crit : >> hi, >> >> this patch should fix the symbian build. >> >> >>

Hello, I have an (Access violation reading location) on line 115 in the fftwrap.c : out[i] = scale*in[i]; with i = 1193 Only with preprocessor active Systems : Visual studio 2005, XP, WB 16000 Hz, last svn. Hope it helps you. Ouss -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of speex-dev-request@xiph.org Sent: dimanche 22 octobre

A couple of things to be noted on the symbian port. 1. the spokn.mmp file is missing window.c, please add that. 2. smallft.c is not required. it has global data that prevents compilation on symbian. 3. lbr_48k_tabels.c has a global variable called dummy_epic_48k_variable on line 37. this has to be commneted out too. 4. check that all tables are declared const. i will shortly post the symbian

Hello to everyone! During building speex library for Symbian OS I encountered some problems. All thess problems can be solved by modifying the speex sources. I don't have access to SVN repository of speex, so I will just describe the changes to be done: 1) mmp file in symbian derictory misses windows.c sources. You need to add this string into speex.mmp: SOURCES windows.c 2) Symbian OS

Just checking to be sure this isn''t a known bug or problem. I couldn''t find a bz for this, but it would appear that tunefs.lustre --print fails on a lustre mdt or ost device if mounted with mmp. Is this expected behavior? TIA mds1-gps:~ # tunefs.lustre --print /dev/mapper/mdt1 checking for existing Lustre data: not found tunefs.lustre FATAL: Device /dev/mapper/mdt1 has not

The frame size is 320 Ouss -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: lundi 23 octobre 2006 18:26 To: Ouss Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Bug with the new preprocessor What frame size are you using? Jean-Marc Ouss a ?crit : > Hello, > > I have an (Access violation reading location) on line 115 in the fftwrap.c

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