similar to: whole linux kernel bitcode

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

Hi In my previous mail I mentioned the project on KCoFI( the control FLow integrity methods for commodity hardware http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ). Will it be more helpful to the community if I do the improvements number #1 and #3 mentioned in my previous mail to the mailing list or if i try to port it to arm architecture? I have decided to go ahead with the improvements

Hello, Is the SVA codebase publically available, and if so, where can I find it? Thanks. -- gregory malecha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110627/4f816aa6/attachment.html>

Hi I want to pursue a project based to improve the existing KCoFI method which is the Control Flow integrity method for commodity os. Since KCoFI is a llvm based project I plan to undertake the project to improve the existing KCoFI method. Following are the improvements that I want to pursue: 1. To improve the call graph used in KCoFI. Implement a stronger call graph. 2. Port the KCoFI to

several errno.h for no good reasons. cleanup losesetup which is not using getopt_long, thus doesn't need getopt.h included. Move stdarg.h include up in losesetup to more proper place. Signed-off-by: maximilian attems <max at stro.at> --- usr/utils/dmesg.c | 1 - usr/utils/losetup.c | 4 +--- usr/utils/mkfifo.c | 1 - usr/utils/nuke.c | 1 - usr/utils/umount.c | 1

Yet another one of those "it would make sense it" posts. Currently, create_dev in do_mounts.c simply unlinks the device and recreates it. This doesn't seem right. If /dev/hda3 has already been created, by some early-userspace app (udev), there's no need to unlink or even parse the name again. Now, when talking about simple block devices, this doesn't make much of a

Various coding style fixes checkpatch warns about. The goal is not to be 100% checkpatch compliant, but to have more consistent coding style. As this is a trivial patch serie, will land in 24 hours in klibc git, unless of course ml review hits a bugger. Checked with size(3) that the generated kinit, fstype, ipconfig and nfsmount are the same. maximilian attems (4): [klibc] ipconfig: reduce

Hi, I ran into a problem when running DSA on Linux kernel (the Kernel version I used is 2.4.31). The analysis was aborted when it tried to do DSNode::mergeTypeInfo on some data structure in the kernel. I have filed a bug report at http://llvm.org/bugs/show_bug.cgi?id=1656. My question is what version of Linux kernel LLVM has been tested on successfully? To run DSA analysis, should I use the

Hi Konstantin, good point. but I my intention is to have something like the llva project. Basically I would like to define a machine that looks as if it has processors running natively llvm code. And when that runs enhance the llvm byte code with some specific instructions. Besides this if I make my measurements on the running of llvm bytecode I can test several platforms simultaneously because I

Hello, With clang/llvm 9.0 adding support for ASM GOTOs, it is now possible to compile the latest Linux kernel with clang without any modification. However, is it possible to generate a single bitcode for the whole Linux kernel? Earlier approaches would involve hacks, like compiling separate bitcode files and then linking with llvm-link, or using wllvm, or using some other wrapper. Frequently,

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

I'd like to announce the LLVMLinux project. This project aims to fully build the Linux kernel using Clang/LLVM on the various architectures supported by the Linux kernel. The project consolidates the work of the lll-project, the PAX team, and Mark Charlebois' work on the ARM kernel. http://llvm.linuxfoundation.org <http://llvm.linuxfoundation.org/> The hope is that this project

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

On 9/19/13 9:53 AM, Herbei Dacian wrote: > > Hi Konstantin, > good point. > but I my intention is to have something like the llva project. If you want something like the LLVA project for user-space applications, then you basically want to use LLVM as-is. The only things missing are the instructions that replace certain in-line assembly sequences that cannot be represented by

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

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

How about state of SVA (Secure Virutal Archtecture)? It seems there is no any demo or prototype produced. Cheers, Liu Jian ---- email to: gjk.liu at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100420/e8dc1b16/attachment.html>

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, If it's not the right place to ask, please forgive me. Currently I'm working on a new operating system concept, called "Om". The first feature would be Android-like apps, coming in *.opk files that would contain all needed resources and source-code expressed in LLVM-IR assembly language. http://sett.com/openminded-os/uid/88508 How does it sound ? Julien

I am interested in type-based verification of LLVM IR in the areas of certified compilation and software verification. It seems to me that the LLVM IR type system is rather informal in the sense that there is no paper with a proper formalization of the type rules, and for example, a proof of soundness for well-formedness of the code. I would like to know if you are aware of any work in this