similar to: [LLVMdev] The LLVMLinux Project

On Fri, Sep 7, 2012 at 10:03 AM, <llvmdev-request at cs.uiuc.edu> wrote: > > Message: 1 > Date: Thu, 06 Sep 2012 21:58:52 -0400 > From: Behan Webster <behanw at converseincode.com> > To: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] The LLVMLinux Project > Message-ID: <504954DC.3010708 at converseincode.com> >

On 10/10/13 22:01, Jakob Stoklund Olesen wrote: > On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > >> One of the issues the LLVMLinux project is having is with the use of >> named registers in the Linux kernel code. The kernel uses something like >> this in order to assign a C variable name to a register (one for each >> kernel

On 20/10/2013 16:22, Behan Webster wrote: > On 10/10/13 22:01, Jakob Stoklund Olesen wrote: >> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >> >>> One of the issues the LLVMLinux project is having is with the use of >>> named registers in the Linux kernel code. The kernel uses something like >>> this in order to

One of the issues the LLVMLinux project is having is with the use of named registers in the Linux kernel code. The kernel uses something like this in order to assign a C variable name to a register (one for each kernel arch). register unsigned long current_stack_pointer asm("esp"); clang doesn't allow this kind of thing which required a patch which less efficient: #define

On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > One of the issues the LLVMLinux project is having is with the use of > named registers in the Linux kernel code. The kernel uses something like > this in order to assign a C variable name to a register (one for each > kernel arch). > > register unsigned long current_stack_pointer

Le 5 nov. 2013 à 19:00, Behan Webster <behanw at converseincode.com> a écrit : > On 11/05/13 09:26, Konstantin Tokarev wrote: >> >> 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: >>> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >>> >>>> One of the issues the LLVMLinux

On 11/05/13 09:26, Konstantin Tokarev wrote: > > 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: >> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >> >>> One of the issues the LLVMLinux project is having is with the use of >>> named registers in the Linux kernel code. The kernel uses

On 11/05/13 11:30, Jean-Daniel Dupas wrote: > > Le 5 nov. 2013 à 19:00, Behan Webster <behanw at converseincode.com > <mailto:behanw at converseincode.com>> a écrit : > >> On 11/05/13 09:26, Konstantin Tokarev wrote: >>> >>> 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk >>> <mailto:stoklund at 2pi.dk>>:

11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: > On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > >>  One of the issues the LLVMLinux project is having is with the use of >>  named registers in the Linux kernel code. The kernel uses something like >>  this in order to assign a C variable name to a

On 11/05/13 00:20, Alp Toker wrote: > On 20/10/2013 16:22, Behan Webster wrote: >> On 10/10/13 22:01, Jakob Stoklund Olesen wrote: >>> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >>> >>>> One of the issues the LLVMLinux project is having is with the use of >>>> named registers in the Linux kernel code.

Hi Tom, I've got a few patches that I'd like to get into 3.5.2 if I can. * r230235 - [mips] Honour -mno-odd-spreg for vector insert/extract when MSA is enabled. o Fixes a failure in the test-suite when -mno-odd-spreg and -mmsa are used together. * r227089 - [mips] Enable arithmetic and binary operations for the i128 data type. o This fixes an instruction selection

Hi all, I'm trying to generate whole program bitcode files for linux kernel and do interprocedural analysis on kernel. I use llvmlinux to compile kernel with clang and generate a bunch of bitcode files successfully. I need to link all these bitcode files together into a single bitcode file, so that I can run whole program analysis. Can I use llvm-link to achieve this? Or should I use

On Mon, Jun 27, 2016 at 9:39 AM, Hahnfeld, Jonas <Hahnfeld at itc.rwth-aachen.de> wrote: > Please have a look at the dedicated mailing list: > http://lists.llvm.org/pipermail/llvm-branch-commits/ > OK, I clicked the offline version of that ML on the main-page of <llvm.org>, so I knew of it. Anyway, I think most people use Git these days. > Please wait for the official

On Sat, Mar 30, 2013 at 5:46 AM, Ikey Doherty <ikey at solusos.com> wrote: > So I tried building various other components with Clang. Notable (and well > known) failures include GLibc and the kernel. I find it more insulting that > the standard components put forth by GNU (such as glibc) rely on their own > non-standard extensions. Simply put: If you want to use one, you must

Hi Dmitry, thanls for sharing. Few comments/questions below: >Here is the list of modifications I had to do in order to link the kernel (I have used llvmlinux with clang and mainline with gcc, the >results are similar): > >1. LLD patches: > - D28094 (Implemented support for R_386_PC8/R_386_8 relocations) Do you remember where it was used ? >5. In

Hi all, I'm trying to generate whole program bitcode files for linux kernel and do interprocedural analysis on kernel. I use llvmlinux to compile kernel with clang and generate a bunch of bitcode files successfully. I need to link all these bitcode files together into a single bitcode file, so that I can run whole program analysis. Should I use libLTO to link all these bitcode files

On 4 November 2013 23:45, James Lyon <jameslyon0 at gmail.com> wrote: > I'm trying to build LLVM on Android rather than the other way around! > Really just to see if it can be done. I worked out the first problem (my > code was written for the old JIT and I'd missed something in updating to > the MCJIT to make it work on ARM). It still doesn't work, but at this

I'll look. On May 16, 2014 8:01 AM, "Jan-Simon Möller" <dl9pf at gmx.de> wrote: > The unrecognized junk is (path shortened, so don't worry): > > .Ldebug_range: > .file 1 "/src/linux/include/linux" "export.h" > .file 2 "/src/linux/init" "main.c" > .file 3

I'm working with an embedded architecture that could, in some situations, run faster if code or data could be located at address zero. I don't know whether this applies to other embedded chips. Despite the name, the flag actually has rather straightforward semantics > from the compiler's perspective. From the gcc docs for > -fdelete-null-pointer-checks: "Assume that

This is getting a bit off-topic, but since Renato brought up RenderScript, I wonder if the Android libbcc interface wouldn't be a cleaner way to approach this problem. It provides more or less the same functionality as MCJIT and in almost the same way. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Renato Golin Sent: Tuesday, November 05,