similar to: [LLVMdev] llvm-ld hangs [[FIXED]]

Forgot to mention that I'm trying to generate LLVM IR. I've also faced this problem while compiling linux kernel with LLVM to generate LLVM IR. On Sun, Sep 28, 2008 at 6:06 PM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote: > Hi, > > I'm trying to compile UML with LLVM. However, LLVM-LD hangs whiile > linking modules. It's consuming 99% of the CPU > >

No, this is not the case. Just because you compile something to LLVM IR does not make the thing you compiled work on every architecture. You may even be able to retarget it to any architecture (it depends), but this in no way means the result will *actually work*. The LLVM IR generated by llvm-gcc is very architecture dependent. Theoretically you could make a C compiler that was mostly C

does that mean .o generated with gcc (.c -> .s and .s -> .o) will not contain llvm ir? i meant, final kernel bitcode ir arch independent and can be JIT with any arch-specific backend. Is it not the case? thanks, ashish On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani > <ashish.bijlani at

Thanks. I actually checked the IR code generated, it seems inline assembly is being handled correctly. The preprocessing is also being done correctly. Here is the asm-offsets.i file snippet.. ... builtin_offsetof(struct crypto_tfm,__crt_ctx))); asm volatile("\n->" : : ); asm volatile("\n->" "__NR_syscall_max" " %0 " "sizeof(syscalls) - 1"

And the code of the Linux kernel compiled by LLVM is also very arch depended, despite any loader and hw access will not work inside the standard LLVM JIT, all the MMU and low-level access stuff will make no sense on a machine other than what was enabled while compiling the kernel. E.g. you would need a whole virtualized HW architecture ala Qemu (et al.) along the JIT. Of course in theory one

Hi, I'm trying to compile UML with LLVM. However, LLVM-LD hangs whiile linking modules. It's consuming 99% of the CPU llvm-ld -v -r -o kernel/built-in.o kernel/sched.o kernel/fork.o kernel/exec_domain.o kernel/panic.o kernel/printk.o kernel/profile.o kernel/exit.o kernel/itimer.o kernel/time.o kernel/softirq.o kernel/resource.o kernel/sysctl.o kernel/capability.o kernel/ptrace.o

On Sep 27, 2008, at 4:34 PM, Ashish Bijlani wrote: > Thanks for the help. I've a couple of questions though: > > How does LLVM deal with inline assembly? It's been implemented piece by piece on an as-needed basis. At this point most of the things people actually use should work. llvm-gcc has seen the Linux kernel, so most usages in there ought to work. The symptoms here

Thanks for the help. I've a couple of questions though: How does LLVM deal with inline assembly? I'm trying to compile kernel and I get this error probably because LLVM is not able to handle inline assembly. I'm using LLVM-2.3 code snippet from "arch/x86_64/kernel/asm-offsets.c" .... #define DEFINE(sym, val) \ asm volatile("\n->" #sym " %0 "

On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote: > If I use GCC to generate asm-offsets.s file, then the build system go > ahead but fails when it generates .so files as Andrew pointed out. You have to generate this with gcc. .c -> .s and .s -> .o need gcc, .c -> .o can use llvm-gcc. The combination has to be fixed up in final linking.

On Fri, Sep 26, 2008 at 9:19 PM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote: > Hi, > > I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all > possible? Yes, but it requires significant hacking, and the result for 2.6 is a mostly bitcode kernel with a few userspace shared libraries linked in as objcode (yes, the kernel builds .so files and includes them

Hi, I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all possible? I get "Not an ELF" error. I pass "-emit-llvm" option to spit LLVM IR, which can be JITed at runtime $ make CROSS_COMPILE=llvm- CFLAGS="-O2 -emit-llvm" Error: not ELF make[2]: *** [scripts/mod/elfconfig.h] Error 1 make[1]: *** [scripts/mod] Error 2 make: *** [scripts] Error 2 using

I plan to use virtualization infrastructure to JIT VM Kernel Code. Michael Engel has done that in the past to have dynamic aspect in the Kernel: http://llvm.org/pubs/2005-03-14-ACP4IS-AspectsKernel.pdf He used L4 based Hypervisor and Virtual Machines. Can this not be done or am I missing something? -Ashish On Sat, Sep 27, 2008 at 3:13 AM, Török Edwin <edwintorok at gmail.com> wrote: >

That is good to hear. The lack of Alpha was purely a lack of time/knowledge of the architecture on my part, hopefully I can start learning some more about how it functions. If you send me either a pointer to appropriate documentation I would be happy to add appropriate information to the page. If you can provide implementations, it would save time, but I don't mind doing a fair portion of the

On Sun, Aug 2, 2009 at 6:09 PM, Carter Cheng<carter_cheng at yahoo.com> wrote: > I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). Code generation actually was

On 2008-09-27 05:19, Ashish Bijlani wrote: > Hi, > > I'm trying to compile linux-2.6.23.16 with llvm-2.3. Is it at all > possible? I get "Not an ELF" error. I pass "-emit-llvm" option to spit > LLVM IR, which can be JITed at runtime > > If you want to build a kernel you can't use the JIT anyway, so why not just build native code? Best regards,

On 2008-09-27 18:29, Ashish Bijlani wrote: > I plan to use virtualization infrastructure to JIT VM Kernel Code. > Michael Engel has done that in the past to have dynamic aspect in the > Kernel: http://llvm.org/pubs/2005-03-14-ACP4IS-AspectsKernel.pdf > > He used L4 based Hypervisor and Virtual Machines. Can this not be done > or am I missing something? > I think you'll

On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > The llvm_ostreams, which you take the address of go out of scope very > quickly, and are only stored by address in the bytecode writer, thus > the writers have a pointer to a stack allocated object they are to > write to. This crashes. The attached version leaks :-) It is a work around. If I understand correctly,

On Wednesday 14 July 2010 17:57:26 Andrew Lenharth wrote: > On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> Is alignment on a field

On 2/15/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > I'll take a hack at the front end support for > __sync_synchronize after this goes in. This is the gcc side of the patch. Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 46956) +++ gcc/llvm-convert.cpp (working copy) @@

I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). --- On Sun, 8/2/09, Andrew Lenharth <andrewl at lenharth.org> wrote: > From: Andrew Lenharth <andrewl at