similar to: [LLVMdev] linking share libraries when building whole-program bitcode file

Nan Zhu <zhunansjtu at gmail.com> writes: > llvm-gcc -c -emit-llvm test.c > > llvm-ld test.o -lpthread //here llvm-ld tells me that "Cannot find library > pthread" $ llvm-gcc -c -emit-llvm test.c $ llvm-ld test.o -lpthread $ ./a.out Error opening '/usr/lib/libpthread.a': /usr/lib/libpthread.a: invalid ELF header -load request ignored. Hello world

Tianwei <tianwei.sheng at gmail.com> writes: > someone suggested me to use gold-plugin, I know nothing about it yet, I will > have a try later. Does anyone have a good solution for this problem? Afaik gold does not help here. I tried it and managed to only generate native code. I'm currently investigating an alternative approach to produce whole-program bitcodes: 1) add

Daniel Dunbar wrote: > On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors > <timo.lindfors at iki.fi> wrote: >> Tianwei <tianwei.sheng at gmail.com> writes: >>> someone suggested me to use gold-plugin, I know nothing about it yet, I will >>> have a try later. Does anyone have a good solution for this problem? >> Afaik gold does not help here. I

On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors <timo.lindfors at iki.fi> wrote: > Tianwei <tianwei.sheng at gmail.com> writes: >> someone suggested me to use gold-plugin, I know nothing about it yet, I will >> have a try later.  Does anyone have a good solution for this problem? > > Afaik gold does not help here. I tried it and managed to only generate >

--emit-llvm?? On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov <vkutuzov at accesssoftek.com>wrote: > Hello everyone, > > I'm working on passing parameters for gold/LTO plug-in and could add this > one as well. > Just need an option name. Could anybody suggest one? > > Viktor > > ----- Original Message ----- > From: "Nick Lewycky" <nicholas at

Hi Nick: Thanks for pointing me to libffi. Recompile LLVM with libffi does solve the problem of printf. But it still has other problems: 1) sinf() returns 0 in the interpreter, but returns correct value in JIT (see hellosin.c) 2) calling pthread_create cause lli to crash in the interpreter mode, but no problem in JIT (see phello.c). My questions are: i) can I call any arbitrary external function

Hello everyone, I'm working on passing parameters for gold/LTO plug-in and could add this one as well. Just need an option name. Could anybody suggest one? Viktor ----- Original Message ----- From: "Nick Lewycky" <nicholas at mxc.ca> To: "Daniel Dunbar" <daniel at zuster.org> Cc: "Kelly, Terence P (HP Labs Researcher)" <terence.p.kelly at

--emit-llvm, if not conflict >>> Paul Davey <plmdvy at gmail.com> 10/30/2009 11:11 AM >>> --emit-llvm?? On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov <vkutuzov at accesssoftek.com> wrote: Hello everyone, I'm working on passing parameters for gold/LTO plug-in and could add this one as well. Just need an option name. Could anybody suggest one? Viktor

Nick Lewycky <nicholas at mxc.ca> writes: > The interpreter uses libffi to make external function calls. However, it > needs to be detected at LLVM's compile time. If you're using the > released packages, we disabled that because we were worried about users > who don't have libffi installed. This seems to be quite a common problem (I too hit it once, thought it

Xu Yang wrote: > Hi Nick: > > The first problem have been solved by calling llvm-ld: > > $ llvm-ld -o hellosin.llvm hellosin.bc -lm > $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc > hello sin: 0.50 Only because the optimizer saw sin(constant) and folded it away. The entire program became 'print constant string'. There is certainly a bug

Hi, when reporting http://llvm.org/bugs/show_bug.cgi?id=5104 I spent quite a while trying to figure out what passes are used by "-O1" so that I could give this list to bugpoint. It turns out -debug-pass=Arguments is mentioned in docs/HowToSubmitABug.html but under a chapter titled "Compile-time optimization bugs" which I naively ignored since my bug was not a compile-time

>I have written a wrapper which includes gcc/g++,ld and llvm counterparts, >it invokes native or llvm compiler and linker according to the options it >receives,after I replace the native tools with my wrapper in libtool >script, I just typed like this > >make CC=wrapper AC_CFLAGS=-emit-llvm > >then I got a bc file of slapd and other tools in clients directory > >The

I'm not completely sure but something like the build system will still call the native linker when it meets a LLVM object file which causes an error. I once tried to modify the codes of gold-plugin, but the trouble is still there,I think we should hack collect2 of llvm-gcc to make it invoke llvm-ld automatically when it receive the -emit-llvm option(I once tried this, but I found that even

Timo Juhani Lindfors wrote: > Nick Lewycky<nicholas at mxc.ca> writes: >> The interpreter uses libffi to make external function calls. However, it >> needs to be detected at LLVM's compile time. If you're using the >> released packages, we disabled that because we were worried about users >> who don't have libffi installed. > > This seems to be

Hi Nick: The first problem have been solved by calling llvm-ld: $ llvm-ld -o hellosin.llvm hellosin.bc -lm $ lli -force-interpreter=true -load=/usr/lib/libm.so hellosin.llvm.bc hello sin: 0.50 The pthread problem remains after llvm-ld: $ lli -force-interpreter=true -load=/lib/libpthread.so.0 phello.llvm.bc 0 lli 0x08796bf8 Segmentation fault For those who are getting "invalid

Hi,all I have written a wrapper which includes gcc/g++,ld and llvm counterparts, it invokes native or llvm compiler and linker according to the options it receives,after I replace the native tools with my wrapper in libtool script, I just typed like this make CC=wrapper AC_CFLAGS=-emit-llvm then I got a bc file of slapd and other tools in clients directory The accessory is the whole-program

Hi, http://llvm.org/doxygen/classllvm_1_1MemoryBuffer.html shows "the file, and that this character will read as '\0'. " as a "verbatim text" box. This looks ugly and is probably a mistake. The attached patch removes this extra @verbatim ... @endverbatim from comments. -------------- next part -------------- A non-text attachment was scrubbed... Name:

On Mon, Mar 20, 2017 at 9:58 PM, Timo Juhani Lindfors <timo.lindfors@iki.fi> wrote: > ıuoʎ <yonjah@gmail.com> writes: >> I have a host running a few guests all configured to autostart. >> I'm also using libvirt-guests to suspend the guests when the host >> restarts or shuts down > > I have a similar setup. I solved it by writing a small daemon that syncs

Hi,all I tried to run the generated whole-program bitcode of BIND,but I got some information: 0 lli 0x0000000000feda16 1 lli 0x0000000000fed88f 2 libpthread.so.0 0x0000003df340eee0 3 libc.so.6 0x0000003df28332f5 gsignal + 53 4 libc.so.6 0x0000003df2834b20 abort + 384 5 libc.so.6 0x0000003df282c2fa __assert_fail + 234 6 lli

* Timo Juhani Lindfors (timo.lindfors at iki.fi) wrote: > Hi, > > Alexandre Gouraud <alexandre.gouraud at enst-bretagne.fr> writes: > > if it does not already exists, could it mean it is a nonsense, then why? > > Why don't you compile your program directly to LLVM bitcode? - In security-testing you sometimes apply black boxing. I've had a similar idea