similar to: [LLVMdev] Why gdb on MacOS doesn't show function names in stack when llvm::JITEmitDebugInfo is set?

With the same source code, gdb on Linux shows function names and on MacOS it doesn't. Why would MacOS be different in respect of this issue? Yuri

I know you haven't been able to get the JIT gdb support to work on FreeBSD (right?), but this is exactly the problem that we ran into that it solves. http://llvm.org/docs/DebuggingJITedCode.html I don't know what heuristic gdb is trying to use to unwind the stack, but it doesn't work. I asked a gdb developer about it two summers ago when I was working on this, but he seemed

Forwarding the patch to commits so that it doesn't get lost. Yuri -------- Original Message -------- From: - Fri Jun 03 12:15:47 2011 X-Mozilla-Status: 0011 X-Mozilla-Status2: 10000000 Return-Path: <llvmdev-bounces at cs.uiuc.edu> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail1.rawbw.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=7.0

On Mon, Jun 21, 2010 at 5:14 PM, Yuri <yuri at rawbw.com> wrote: > I am on FreeBSD and gdb-7.1 seems to be broken. It fails to set breakpoints > in shared libs. using symbol-file causes this message: > > (gdb) symbol-file /usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so > Load new symbol table from > "/usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so"? (y

Since FreeBSD is an ELF target, this should work fine. I've also tested that this works in 32-bit by building gdb and llvm in 32-bit mode and testing this stuff while running on a 64-bit OS. I would try setting a breakpoint in gdb on 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being called, and that getELFWriterInfo returns something. If that function actually

When gdb is stopped in a function with no known start address, it has to make a guess about how to get the caller's rip. Either we assume that the saved rip is at rsp+8, or we assume that the saved rip is found via the rbp register. But it's a guess either way - gdb can't find the start of the function so it can't know which is the correct method. It would be nice if it could

The size of an address on the target machine in the 32-bit DWARF format is NOT restricted to 32-bits. The size of an address on the target machine is specified in the DWARF table headers. For example, in the DWARF-3 Specification, section 7.5.1, the unit_length field is used to specify whether the DWARF format is 32-bit or 64-bit (as well as defining the length of the table). However the

On 06/21/2010 14:14, Reid Kleckner wrote: > Since FreeBSD is an ELF target, this should work fine. I've also > tested that this works in 32-bit by building gdb and llvm in 32-bit > mode and testing this stuff while running on a 64-bit OS. > > I would try setting a breakpoint in gdb on > 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being > called,

On Sat, Jun 19, 2010 at 8:53 PM, Yuri <yuri at rawbw.com> wrote: > I have followed http://llvm.org/docs/DebuggingJITedCode.html, used the > latest release gdb-7.1 (from March 18, 2010) and got this stack: > > (gdb) bt > #0  0x35532156 in ?? () > #1  0x355320f8 in ?? () > #2  0x35532098 in ?? () > #3  0x3553202e in ?? () > #4  0x34a5661a in ?? () > #5  0x349d9bd9

I run some code in JIT on x86-64 architecture. Even though llvm::NoFramePointerElim is set to true, I still see weird stack in gdb, see below. 800b485a4 is the current rip register where gdb stopped. Then many others values aren't valid. Then there is value that looks ok again. Why gdb can't determine stack? Yuri -- stack -- #0 0x0000000800b485a4 in ?? () #1 0x000000000000005f in

Yuri, on which host? 2011/8/17 Yuri <yuri at rawbw.com>: > In r134967 it still worked, and in r137742 it now doesn't. > I used such flags: --enable-assertions --enable-shared --enable-libffi > --enable-debug-runtime --enable-debug-symbols --disable-optimized > > Before build would create directory tools/llvm-shlib under the build > tree. Now it is missing. In my

On Apr 17, 2013, at 7:26 PM, Yuri <yuri at rawbw.com> wrote: > On 10/02/2012 13:01, Duncan Sands wrote: >> >> I think Chris is the right person to look at this, hopefully he will. > > Now 5 months passed. I updated the patch for this current revision. > Can anybody review this and check in please? > > http://llvm.org/bugs/show_bug.cgi?id=13163 >

hi ambika, I am not sure about this solution as i just started working in this field. How about taking analogy of a problem which ask us to find nearest common parent of two nodes in a tree. Let me know if I can be corrected. - Anubhav intern IIT M B. Tech 4th year CSE VIT University, Vellore. On 31 May 2010 22:30, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list

I've built clang+llvm in an object directory successfully, and I'm sure others have. I'd guess the problem is the symlink, so I'd give it a shot without it. Reid On Thu, Jun 10, 2010 at 7:43 AM, Diego Iastrubni <diegoiast at gmail.com> wrote: > can you tell what commands exactly did you use? > > What I usually do is: > > svn co llvm... > mkdir

-Wenum-compare is buggy / bogus. We should turn this warning off in our build scripts if possible. On Tue, Jun 26, 2012 at 5:15 PM, Yuri <yuri at rawbw.com> wrote: > I just switched gcc from 4.6.2 to 4.7.1 and see the massive amount of > warnings, see few examples below. > They mostly didn't exist with gcc-4.6.2. > > rev.159224 > > Yuri > > >

Have you found http://llvm.org/docs/DebuggingJITedCode.html? The JIT already has support for something like this for gdb's benefit. Perftools and valgrind just don't know how to find it yet. On Sat, Jun 19, 2010 at 2:03 PM, Yuri <yuri at rawbw.com> wrote: > This new option (--jit-emit-debug-function-range) will allow to output > function information for memory ranges that

Yuri <yuri at rawbw.com> writes: > How can I copy the value from another BB? > PHI instruction with one argument would fit, but it requires that all > arguments are in immediately preceding BBs. Using a value is not restricted to the BB where you created it.

can you tell what commands exactly did you use? What I usually do is: svn co llvm... mkdir llvm/tools/clang svn co llvm/tools/clang mkdir cmake-build cd cmake-build cmake ../ make Try something similar by running "../configure", it should work. On Thu, Jun 10, 2010 at 11:23 AM, Yuri <yuri at rawbw.com> wrote: > I did these steps: > * checked out llvm trunk, and clang

----- Original Message ---- > From: Chris Lattner <clattner at apple.com> > To: Yuri <yuri at rawbw.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Sun, February 20, 2011 3:26:35 AM > Subject: Re: [LLVMdev] Announcing: LLVM 2.9 Tentative Release Schedule > > > On Feb 19, 2011, at 8:05 PM, Yuri wrote: > > > On 02/19/2011 14:52, Yuri wrote: > >>

Hello Yuri, Did you look at http://cfe.llvm.org/compatibility.html yet? --Sam ----- Original Message ----- > From: Yuri <yuri at rawbw.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Cc: > Sent: Saturday, June 11, 2011 12:22 PM > Subject: [LLVMdev] Build of C++ project with clang++ fails (local symbol 1: discarded in section `xxx') > >