similar to: [LLVMdev] Can I read llvm version through API?

Hi Yuri, > Is there an API function exported from libLLVM.so that would return the > version of llvm compiler used? > I would like to be able to read not only 2.8 but also the precise source > version identifier, like svn revision for example. And maybe the build date. maybe utils/GetSourceVersion will help. Ciao, Duncan.

On 07/21/2010 03:39, Duncan Sands wrote: > maybe utils/GetSourceVersion will help. > No, I meant can I read the version from the shared library libLLVM.so? I guess the answer is "no". So I will make a patch for this. Yuri

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

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 05/31/2011 12:50, Duncan Sands wrote: > probably it's best to just go ahead and implement this (with PACKAGE_VERSION > being auto-computed from these) and see if anyone objects : But this only works for C++ apps compiled with headers. It's better to implement version to be returned through the API exported from libLLVM.so Yuri

Please check in this patch. Thanks, Yuri -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-version URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100831/632e9759/attachment.ksh>

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

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

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

Hi Yuri, On 31/05/11 22:29, Yuri wrote: > On 05/31/2011 12:50, Duncan Sands wrote: >> probably it's best to just go ahead and implement this (with PACKAGE_VERSION >> being auto-computed from these) and see if anyone objects : > > But this only works for C++ apps compiled with headers. > It's better to implement version to be returned through the API exported from

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

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

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

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

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

I have ran under valgrind memcheck the process using libLLVM-2.9.so (rev.126022) and got several errors: ==24227== Invalid read of size 1 ==24227== at 0x40274C9: memcpy (mc_replace_strmem.c:497) ==24227== by 0x40D5B84: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in

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 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 Thu, Apr 29, 2010 at 6:31 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Wed, Apr 28, 2010 at 10:48 AM, Yuri <yuri at tsoft.com> wrote: >> Jeffrey Yasskin wrote: >>> >>> We currently use two different techniques to get whole libraries >>> included into the .so. On Linux (gnu ld and gold), we pass >>> --whole-archive, while on