similar to: [PATCH] PV-GRUB: xfs support

I just compiled the two attached files in 32-bit mode and ran it. It printed efcdab8967452301. I verified via objdump that the my_bswap function contains the follow assembly which I believe matches the assembly you linked to on godbolt. _my_bswap: 1f70: 55 pushl %ebp 1f71: 89 e5 movl %esp, %ebp 1f73: 8b 55 08 movl 8(%ebp), %edx 1f76: 8b 45 0c movl 12(%ebp), %eax 1f79: 0f c8

Add a couple of documentation details about PV-GRUB support - the menu.lst content can be passed as a ramdisk. - virtual partitions are not supported. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> diff -r b8d2a4134a68 stubdom/README --- a/stubdom/README Wed Mar 03 17:41:58 2010 +0000 +++ b/stubdom/README Wed Mar 03 20:42:53 2010 +0100 @@ -52,11 +52,17 @@ extra =

Hi everyone, I found that Clang -O0 performs optimizations that undermine dynamic bug-finding tools. First, most bug finding tools such as ASan, Valgrind, Dr. Memory, Mudflap, Purify and Safe Sulong (on which I am working) rely on detecting errors during the execution of the program. They either insert additional checks during compile-time or during run-time which are executed when the program

Hi all, As of r141677 I have a failing regression test, see below. This is for LLVM built with clang on a Intel Atom running FreeBSD8.2. Should I file a bug for this? Thanks, Ed. ******************** TEST 'LLVM :: CodeGen/X86/bswap.ll' FAILED ******************** Script: -- /usr/home/emeewis/build/llvm-debug-clang-configure/Debug+Asserts/bin/llc <

Hi, The following patches add support for ext4 and btrfs to PV-GRUB. These patches are taken nearly verbatim from those provided by Fedora and Gentoo. We''ve been using these patches for the PV-GRUB images available in EC2 for some time now with no problems. Changes from v1: - Makefile has been changed to check the exit code from patch - The btrfs patch has been rebased to apply

It's equivalent to __printf, so prefer __scanf. Signed-off-by: Joe Perches <joe at perches.com> --- include/linux/compiler-gcc.h | 3 ++- include/linux/kernel.h | 8 ++++---- include/xen/xenbus.h | 4 ++-- scripts/checkpatch.pl | 6 ++++++ 4 files changed, 14 insertions(+), 7 deletions(-) diff --git a/include/linux/compiler-gcc.h

It's equivalent to __printf, so prefer __scanf. Signed-off-by: Joe Perches <joe at perches.com> --- include/linux/compiler-gcc.h | 3 ++- include/linux/kernel.h | 8 ++++---- include/xen/xenbus.h | 4 ++-- scripts/checkpatch.pl | 6 ++++++ 4 files changed, 14 insertions(+), 7 deletions(-) diff --git a/include/linux/compiler-gcc.h

Since the vTPM implementations are being incorproated into Xen and possibly upstream Linux, I would like to see if this protocol change could be added before we have significant legacy implementations. If not, I still think it would be useful as either a v2 or negotiated protocol change. The current vTPM protocol is a copy of the network protocol. This was likely done for ease of implementation,

bswapdi2 for i386 is correct Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into eax. Those are each bswapped. The ABI for the return is edx contains bits [63:32] and eax contains [31:0]. This is opposite of how the register were loaded. ~Craig On Sun, Nov 25, 2018 at 10:36 AM Craig Topper <craig.topper at gmail.com> wrote: > bswapsi2 on the x86-64 isn't using

klibc now runs on the CRIS archtitecture. The patch below is against 0.146. Most of the changes are trivial but the new files in libgcc requires some comments. __negdi2.c: The CRIS port fallbacks to C-code for negdi2. The code in __negdi2.c is copied from libgcc2.c but with modified typenames. I would really appreciate if someone could check if it seams sane. crisarith.c: CRIS has no built-in

Hi, I would like to propose a potential solution to a bug that involves coroutine and pthread_self(). Description of the bug can be found in https://bugs.llvm.org/show_bug.cgi?id=47833. Below is a summary: pthread_self() from glibc is defined with "__attribute__ ((__const__))". The const attribute tells the compiler that it does not read nor write any global state and hence always

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

Hi, R core developers, I work in the Swiss Institute of Bioinformatics. We have two clusters of Intel Itanium2 clusters for bioinformaticians to crank their data. One piece of software they use heavily is R and BioConductors. I ported the R codes and R packages to this platform already, and am working on optimizing their performance. I'm using Intel C/C++ compiler on this platform running

On 11/30/2012 6:36 PM, Lang Hames wrote: > > > RBP is used as the frame pointer on x86 (hence its automatic > appearance in your code), and shouldn't be allocated to any vreg in > function bar. Loading/saving RBP should be managed by the stack frame > setup/teardown code. > If it doesn't already, your allocator should filter out reserved > registers (See