similar to: [LLVMdev] Compiling user mode linux with LLVM

Hello, I've recently started working on compiling UML with LLVM: the goal is to produce a bitcode version of vmlinux. With some tweaks to the build process, I can use: make ARCH=um CROSS_COMPILE=llvm- CFLAGS="-emit-llvm" to produce vmlinux bitcode. The question is with respect linker script support. Since llvm-ld does not support linker scripts--please correct me if I'm

Sam, Nick, thank you both for your reply--that was what I thought but wanted to check. The JIT compiler for x86 is pretty robust. Are you aware of any comprehensive list of the most "significant" functional differences between the interpreter and the JIT for x86, i.e. a TODO list? grep -I todo * ? I've just got a rather large project here (user-mode Linux) which works with the

Hello Matt, The interpreter doesn't support external functions at all. This includes the printf function from the glibc library. That's why the signal causes a segfault. If you're interested in bringing the interpreter up-to-date with the JIT compiler, I would welcome it since JIT compilation isn't supported on all platforms. --Sam ----- Original Message ---- > From:

Linker changes to add the VMI MACH_TEXT area into the kernel text section. This area layout is heavily influenced by magic to overlap exactly with the 32-byte VMI ROM entry points, allowing the kernel to copy the VMI ROM over the native section. As use of magic is on the decline, this approach is being phased out in favor of the more modern approach of the inline implementation. The translation

Linker changes to add the VMI MACH_TEXT area into the kernel text section. This area layout is heavily influenced by magic to overlap exactly with the 32-byte VMI ROM entry points, allowing the kernel to copy the VMI ROM over the native section. As use of magic is on the decline, this approach is being phased out in favor of the more modern approach of the inline implementation. The translation

I compiled the pvops kernel like this : [root@localhost xen-4.0.0]# ls buildconfigs config Config.mk.orig dist extras install.sh Makefile README tools xen build-linux-2.6-pvops_x86_32 Config.mk COPYING docs file linux-2.6-pvops.git messages stubdom unmodified_drivers [root@localhost build-linux-2.6-pvops_x86_32]# make -j2 bzImage

I compiled the pvops kernel like this : [root@localhost xen-4.0.0]# ls buildconfigs config Config.mk.orig dist extras install.sh Makefile README tools xen build-linux-2.6-pvops_x86_32 Config.mk COPYING docs file linux-2.6-pvops.git messages stubdom unmodified_drivers [root@localhost build-linux-2.6-pvops_x86_32]# make -j2 bzImage

Hi, I'm trying to compile linux kernel with llvm to generate llvm ir (bitcode). It seems like llvm-ld doesn't accept any linker scripts. How do I deal with vmlinux.lds in such a case? How did people who have compiled linux kernel with llvm deal with this in the past? Thanks, Ashish

OK, here's another go-around. This patch leaves the bzImage itself unmodified, but it changes the payload into an ELF file. That is, the 32-bit decompression/relocation+compressed kernel is now a properly formed ELF file. One thing that fell out of this is that code32_start end up being a pointer to the ELF header rather than an entrypoint. Rather than reproducing Vivek's (?) hack of

OK, here's another go-around. This patch leaves the bzImage itself unmodified, but it changes the payload into an ELF file. That is, the 32-bit decompression/relocation+compressed kernel is now a properly formed ELF file. One thing that fell out of this is that code32_start end up being a pointer to the ELF header rather than an entrypoint. Rather than reproducing Vivek's (?) hack of

This patch updates x86_64 linker script to pack any .note.* sections into a PT_NOTE segment in the output file. To do this, we tell ld that we need a PT_NOTE segment. This requires us to start explicitly mapping sections to segments, so we also need to explicitly create PT_LOAD segments for text and data, and map the sections to them appropriately. Fortunately, each section will default to its

I tend to use the same tool-chain across various hosts so I made this very simple patch that allows you to pass the cross-compiler name to make ( e.g. make CROSS_COMPILE=i686-nptl-linux-gnu-). I'm not sure if patches should be attached or just pasted inline so I did both this time. BTW, it's relative to syslinux 4 but the same changes work with syslinux 3 although the patch won't

On 10/11/2017 3:30 PM, Thomas Garnier wrote: > Changes: > - patch v1: > - Simplify ftrace implementation. > - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. > - rfc v3: > - Use --emit-relocs instead of -pie to reduce dynamic relocation space on > mapped memory. It also simplifies the relocation process. > - Move the start the module

Introduce NOKPROBE_SYMBOL() macro which builds a kprobe blacklist in build time. The usage of this macro is similar to the EXPORT_SYMBOL, put the NOKPROBE_SYMBOL(function); just after the function definition. If CONFIG_KPROBES=y, the macro is expanded to the definition of a static data structure of kprobe_blackpoint which is initialized for the function and put the address of the data structure

Thanks to Andrew for pointing these out. This patch moves the parvirtprobe section into .init.data: it's only used in very very early boot, and for similar reasons, puts lguest_maybe_init and lguest_memory_setup in init.text. As well as fixing some warnings, this frees up a tiny bit more memory. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r ecec388180b2

Thanks to Andrew for pointing these out. This patch moves the parvirtprobe section into .init.data: it's only used in very very early boot, and for similar reasons, puts lguest_maybe_init and lguest_memory_setup in init.text. As well as fixing some warnings, this frees up a tiny bit more memory. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -r ecec388180b2

On 10/12/2017 10:34 AM, Thomas Garnier wrote: > On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky <thomas.lendacky at amd.com> wrote: >> On 10/11/2017 3:30 PM, Thomas Garnier wrote: >>> Changes: >>> - patch v1: >>> - Simplify ftrace implementation. >>> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. >>> - rfc

From: Joerg Roedel <jroedel at suse.de> The file contains only code related to identity mapped page-tables. Rename the file and compile it always in. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/boot/compressed/Makefile | 2 +- arch/x86/boot/compressed/{kaslr_64.c => ident_map_64.c} | 9 +++++++++ arch/x86/boot/compressed/kaslr.c

Since CPP is being used with CFLAGS, it should be in lock-step with CC, to avoid having to specify both CC and CPP for the build. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-03-19/config/StdGNU.mk =================================================================== --- 2007-03-19.orig/config/StdGNU.mk 2007-03-08 09:37:32.000000000 +0100 +++ 2007-03-19/config/StdGNU.mk

With CONFIG_PARAVIRT, the kernel .text is littered with a bunch of calls to pv_irq_ops function pointers, like: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) In non-Xen paravirt environments -- including native, KVM, Hyper-V, and VMware -- the above code gets patched by native_patch() to look like this instead: pushfq pop %rax nopl 0x0(%rax,%rax,1) So in most scenarios,