similar to: [LLVMdev] Why --enable-shared options doesn't cause all executables to be linked to it?

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

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,

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 06/21/2010 18:01, Reid Kleckner wrote: > One thing you could do as a temporary work around is to link with LLVM > statically. There's already an open bug where if the JIT is in a > shared library, then you cannot run the program twice under gdb > without restarting gdb, which is really annoying. > > This affects me, and I do intend to fix it eventually. I'm not sure

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

I am getting this error on FreeBSD-8.1 (amd64): llvm[1]: Linking Debug+Asserts Shared Library libLLVM-2.8svn.so /tmp/llvm-svn/llvm-objects/Debug+Asserts/lib/libLLVMSystem.a(Program.o)(.text+0xa2b): In function `llvm::sys::Program::Execute(llvm::sys::Path const&, char const**, char const**, llvm::sys::Path const**, unsigned int, std::basic_string<char, std::char_traits<char>,

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

Pekka Jääskeläinen wrote: > On 04/28/2010 11:42 AM, Yuri wrote: >> Looks like this is platform dependent. > > Yep, works fine here on Debian 5.0/x86_64 with gcc 4.3.2. > > Did you build with make REQUIRES_RTTI=1 which is required > as of LLVM 2.7 to get RTTI for LLVM symbols? > No. If this is a hack to get the command 'g++ -shared -o libLLVM-2.7.so -lXXX -lXXX

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

Jeffrey Yasskin wrote: > I just tried it again on trunk (not 2.7) on OSX 10.5, and it works. > What platform are you on? Does it work with another version of gcc? > Looks like this is platform dependent. libLLVM-2.7.so created has size only 4145 bytes and all llvm symbols are missing. It's empty because there are no .o modules included into it, only libraries through -l options

On 06/21/2010 11:14, Reid Kleckner wrote: > Yes, I have some version of 7.1 installed on my workstation and it works for me. I repeted what you did step by step and it still doesn't work for me, see log below. Two differences: I am on FreeBSD and it's 32 bit. It's svn revision 105825. Plus I have few unrelated patched applied to it which shouldn't matter. Yuri $ lli

On Wed, Apr 28, 2010 at 9:23 AM, Yuri <yuri at tsoft.com> wrote: > Pekka Jääskeläinen wrote: >> >> On 04/28/2010 11:42 AM, Yuri wrote: >>> >>> Looks like this is platform dependent. >> >> Yep, works fine here on Debian 5.0/x86_64 with gcc 4.3.2. >> >> Did you build with make REQUIRES_RTTI=1 which is required >> as of LLVM 2.7 to

On Tue, May 4, 2010 at 5:31 PM, Yuri <yuri at tsoft.com> wrote: > Jeffrey Yasskin wrote: >>> >>> Would you try the patch at >>> http://codereview.appspot.com/download/issue968046_1.diff? It should >>> make the BSDs fall into the same path as Linux, and since you use gnu >>> ld, that should work for you. >>> >> >> Ping?

On Wed, Apr 28, 2010 at 1:42 AM, Yuri <yuri at tsoft.com> wrote: > Jeffrey Yasskin wrote: >> >> I just tried it again on trunk (not 2.7) on OSX 10.5, and it works. >> What platform are you on? Does it work with another version of gcc? >> > > Looks like this is platform dependent. libLLVM-2.7.so created has size only > 4145 bytes and all llvm symbols are

On Thu, Feb 20, 2014 at 1:58 PM, Yuri <yuri at rawbw.com> wrote: > On 02/18/2014 00:44, 杨勇勇 wrote: > >> I ported llvm backend and lldb recently. Both tools can basically work. >> lldb is able to debug programs in asm style and frame unwinding is OK. >> >> But "frame variable XX" does not work because lldb is not able to >> determine >> the

Jeffrey Yasskin wrote: >> Would you try the patch at >> http://codereview.appspot.com/download/issue968046_1.diff? It should >> make the BSDs fall into the same path as Linux, and since you use gnu >> ld, that should work for you. >> > > Ping? > Sorry for the delay. Here is what I am getting after applying the patch: gmake[2]: Leaving directory

On 01/11/2011 16:16, Rob Nikander wrote: > I just downloaded and compiled LLVM and I'd like to use the JIT API in > a project that I've got in Xcode. I'm confused because I thought I > could use LLVM like a library, but it seems I can't simply include > some headers and link to lib, as usual. Or can I? I don't see a > framework or dylib file, which I would

Hi, I'm trying to use llvm/clang to cross compile to sparcv9. The following works with a -march=sparc, but yields errors for sparcv9. Are there some other flags that need to be specified? Thanks, Tarun > clang -m64 -emit-llvm test.c -c -o test.bc > llc -march=sparcv9 test.bc -o hello.s ExpandIntegerResult #0: 0x8a6c478: i64 = GlobalAddress<[4 x i8]* @.str> 0 [ORD=1] [ID=0] Do

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

On 04/28/2010 11:42 AM, Yuri wrote: > Looks like this is platform dependent. Yep, works fine here on Debian 5.0/x86_64 with gcc 4.3.2. Did you build with make REQUIRES_RTTI=1 which is required as of LLVM 2.7 to get RTTI for LLVM symbols? -- Pekka