Tag Archives: fedora

Alignment errors on Fedora ARM

Here’s what you should do if you get a compile error like this on Fedora ARM:

error: cast increases required alignment of target type [-Werror=cast-align]
  1. If it’s an easy fix with little chance of breaking things, then fix it.
  2. If it’s on a performance critical path, especially if it causes a measurable slow down, then fix it.
  3. Otherwise, disable the warning. One way is to add:
    #pragma GCC diagnostic ignored "-Wcast-align"
    

BTW I will delete any comment on this post unless you show you have read the next part:

The background is that on certain architectures (ARM and MIPS are the main ones) the processor cannot load or store values from memory which is not aligned. Say you had a protocol which sent a 1 byte length field followed by a 4 byte data field:

+-------+-------+-------+-------+-------+- - - -
| len   | <---------- data -----------> |
+-------+-------+-------+-------+-------+- - - -

If you loaded this into malloc’d memory and used a C struct like this to access it:

struct {
  uint8_t len;
  int32_t data;
} __attribute__((packed));

then accesses to p->data might trap. The malloc’d memory, hence the struct, is aligned, and so the data field is not aligned.

What happens in Fedora is the kernel gets called. It sees a FAULT_CODE_ALIGNMENT fault, looks at the failed load instruction, emulates it, then returns back to your code. This fixup step is slow.

However it’s not a bug. Fedora only runs on recent ARM chips that can now do some unaligned accesses in hardware and always generate traps for ones they can’t handle.

Your code will still run fine assuming you don’t change the /proc/cpu/alignment setting. But if these fixups are frequent it is plausible that they could cause a performance problem.

Fixing these can be hard, and is more likely to create bugs (as we found out when trying to fix alignment bugs in hivex).

Since the most popular development architecture (x86) has always been able to handle unaligned accesses in hardware, developers are going to keep adding unaligned accesses to their programs. In the Intel Haswell chips, there isn’t even a performance penalty (in fact, it’s likely to be faster to squeeze your structs as much as possible, even if it makes them unaligned). ARM has gradually been adding the ability to handle unaligned access too, so eventually one hopes the problem will go away for developers.

5 Comments

Filed under Uncategorized

Fedora 21 has a working OCaml ARM64

Update: Thanks to Peter Robinson, there is now a build of OCaml for aarch64 in the Fedora repository.

I have backported the upstream ARM64 support into Fedora 21’s OCaml, so you can now use it to generate native ARM64/AArch64 binaries. If you don’t have hardware, use qemu to emulate it instead.

6 Comments

Filed under Uncategorized

How to run aarch64 binaries on an x86-64 host using qemu userspace emulation

Note: This is the Fedora version of this Debian document so full credit must go to Debian and SuSE for assembling the bits.

Qemu (not quite upstream) now has ARM 64 bit emulation. It only does the userspace emulation at the moment, although system emulation is being worked on. This is much faster than the ARM “Foundation Model” (basically ARM’s proprietary emulator).

You will need to clone SuSE’s ARM64 qemu git repository and compile it statically linked (configure it with --target-list=arm64-linux-user --static). Static glib2 for Fedora is here.

You will also need to download this Fedora 19 arm64 disk image and convert it into a root filesystem (unfortunately this process requires, just temporarily, 14 GB of free disk space — should have used virt-sparsify!!):

mkdir /tmp/arm64
cd /tmp/arm64
tar zxf F19-aarch64-efi.tar.xz
virt-tar-out -a ./F19-aarch64-efi/aarch64-efi.img / - |
    sudo tar xf -
rm -rf F19-aarch64-efi

So now what you should have is a statically linked qemu-arm64 binary (that’s the userspace arm64 emulator), and a root filesystem containing lots of arm64 binaries. To run them we’ll need to set up a systemd binfmt handler, which will notice when we’re about to try to run an arm64 binary and inject our emulator so it’s possible to run it on our host (which is obviously not arm64 since that hardware is unobtainium for most mortals).

Copy the statically linked qemu-arm64 binary into the chroot, ie:

cp ./arm64-linux-user/qemu-arm64 /tmp/arm64/

Create a binfmt file /etc/binfmt.d/qemu-arm64.conf with the content below. Note that it refers to the absolute path /qemu-arm64 which (will be) correct once we chroot into the arm64 filesystem.

# AArch64 binaries.
:qemu-arm64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/qemu-arm64:OC
$ sudo service systemd-binfmt restart

Check that /proc/sys/fs/binfmt_misc/qemu-arm64 has been created with the expected contents.

Now you’re ready to go!

$ cd /tmp/arm64
$ sudo mount -o bind /dev ./dev
$ sudo mount -o bind /dev/pts ./dev/pts
$ sudo mount -o bind /proc ./proc
$ sudo mount -o bind /sys ./sys
$ sudo chroot .
# file bin/ls
bin/ls: ELF 64-bit LSB executable, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux
3.7.0,
BuildID[sha1]=0x31bcaf7de1bb3c6a4400983ac31f0dff1bbfc394, stripped
# /bin/ls
bin   dev  home  lib64	     media  opt   qemu-arm64  run   srv  tmp  var
boot  etc  lib	 lost+found  mnt    proc  root	      sbin  sys  usr
# uname -a
Linux choo.home.annexia.org 3.8.0 #1 SMP Thu Oct 10
14:11:18 UTC 2013 aarch64 aarch64 aarch64 GNU/Linux

And somehow convince yourself you really are running arm64 binaries!

One problem I had is the supplied chroot is quite minimal and I’m not exactly sure how to install more. But it’s fun to play and a lot faster than the Foundation Model.

Update #1

# arch
aarch64

Update #2

The /etc/yum.repos.d/stage4.repo file in the disk image above is broken. Peter Robinson notes that you can use http://arm.koji.fedoraproject.org/aarch64/stage4/ as a yum repo for installing more packages.

Update #3

Outside the chroot — when you’re running commands in the chroot — you’ll see qemu interpreting the arm64 binaries in ps output:

$ ps ax | grep qemu
26051 pts/14   S      0:03 /qemu-arm64 /bin/bash -i
28170 pts/14   S      0:00 /qemu-arm64 /bin/su rjones
28171 pts/14   S      0:01 /qemu-arm64 /bin/bash
28226 pts/14   Sl+    0:03 /qemu-arm64 /bin/git clone git://libvirt.org/libvirt.git
28228 pts/14   S+     0:12 /qemu-arm64 /usr/libexec/git-core/git index-pack --stdin -v --fix-thin --keep=fetch-pack 28226 on choo.home.annexia.org

6 Comments

Filed under Uncategorized

Install Fedora 20 with virt-builder

Fedora 20 has been released. You can now install it in a VM using virt-builder:

$ virt-builder fedora-20

This creates a file fedora-20.img. You can import this into libvirt by using the command here.

3 Comments

Filed under Uncategorized

Virt-builder making VMs in around 3̶0̶ 16 seconds

The newest upstream virt-builder can now build simple VMs in around 30 seconds (this is on a machine with a hard drive, it’s faster if you have SSDs):

$ virt-builder ubuntu-12.04
[   0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   1.0] Creating disk image: ubuntu-12.04.img
[   1.0] Uncompressing: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   9.0] Opening the new disk
[  33.0] Setting a random seed
[  33.0] Random root password: z6T5zQiqIIy0yZfA [did you mean to use --root-password?]
[  33.0] Finishing off
Output: ubuntu-12.04.img
Total usable space: 2.9G
Free space: 2.1G (73%)

Even installing packages in the VM, it’s still taking under 1 minute:

$ virt-builder ubuntu-12.04 --install nmap
[   0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   1.0] Creating disk image: ubuntu-12.04.img
[   1.0] Uncompressing: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[  10.0] Opening the new disk
[  34.0] Setting a random seed
[  34.0] Random root password: Mt3kxbEsBqumG6bR [did you mean to use --root-password?]
[  34.0] Installing packages: nmap
[  53.0] Finishing off
Output: ubuntu-12.04.img
Total usable space: 2.9G
Free space: 2.0G (70%)

The major changes are: It will use pxzcat (parallel xzcat) if available, and it will bypass the virt-resize step if you don’t specify the --size option (or if you make sure the templates are the right size to start with).

Update:

On a machine with an Intel SSD and parallel xzcat installed:

$ virt-builder ubuntu-12.04
[   0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   1.0] Creating disk image: ubuntu-12.04.img
[   1.0] Uncompressing: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[  12.0] Opening the new disk
[  16.0] Setting a random seed
[  16.0] Random root password: JdIsqD5QB64yImYL [did you mean to use --root-password?]
[  16.0] Finishing off
Output: ubuntu-12.04.img
Total usable space: 2.9G
Free space: 2.1G (73%)

Leave a comment

Filed under Uncategorized

Fedora 20 Virtualization Test Day is on Tuesday

Fedora 20 virtualization test day is this Tuesday. Come and join us on FreeNode IRC in #fedora-test-day.

Ideally you would have one of the following in decreasing order of preference:

  • Fedora 20 installed on a physical machine (the best option!)
  • Fedora 20 installed in a virtual machine — make sure you give the VM plenty of disk space and RAM.
  • Fedora 19 with virt-preview or with updated F20 packages via some other route (eg. compiling from SRPMs).

But we’re also around in case you just want to chat about upcoming Fedora features.

1 Comment

Filed under Uncategorized

OCaml 4.01.0 entering Rawhide

After using OCaml for around 10 years it is still my favourite language, and it’s amazing how far ahead of other programming languages it remains to this day.

OCaml 4.01.0 was released on Thursday and I’m putting it into Fedora Rawhide over this weekend.

Debuginfo is now (partially) enabled. The OCaml code generator has produced good quality DWARF information for a while, and now you are able to debug OCaml programs in gdb under Fedora:

$ sudo debuginfo-install ocaml ocaml-findlib
$ gdb /usr/bin/ocamlfind
[...]
Reading symbols from /usr/bin/ocamlfind...
Reading symbols from /usr/lib/debug/usr/bin/ocamlfind.debug...done.
done.
(gdb) break frontend.ml:469
Breakpoint 1 at 0x432500: file frontend.ml, line 469.
(gdb) run query findlib -l
Starting program: /usr/bin/ocamlfind query findlib -l

Breakpoint 1, camlFrontend__query_package_1199 () at frontend.ml:469
469	let query_package () =
(gdb) bt
#0  camlFrontend__query_package_1199 () at frontend.ml:469
#1  0x000000000043a4b4 in camlFrontend__main_1670 () at frontend.ml:2231
#2  0x000000000043aa86 in camlFrontend__entry () at frontend.ml:2283
#3  0x000000000042adc9 in caml_program ()
#4  0x00000000004834be in caml_start_program ()
#5  0x000000000048365d in __libc_csu_init ()
#6  0x0000003979821b75 in __libc_start_main (main=0x42aa60 <main>, argc=4, 
    ubp_av=0x7fffffffde38, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffde28) at libc-start.c:258
#7  0x000000000042aaa9 in _start ()
(gdb) list
464	;;
465	
466	
467	(************************** QUERY SUBCOMMAND ***************************)
468	
469	let query_package () =
470	
471	  let long_format =
472	    "package:     %p\ndescription: %D\nversion:     %v\narchive(s):  %A\nlinkopts:    %O\nlocation:    %d\n" in
473	  let i_format =

GDB only understands location data at the moment, so you can’t yet query variables (although I understand OCaml generates the correct DWARF info for this, GDB just doesn’t know how to print OCaml expressions).

There will also be some limitations on the debuginfo built at first. At the moment it doesn’t include debuginfo for OCaml libraries called from an OCaml program, because of problems that need to be worked out with the toolchain. Mixed OCaml binary / C library debuginfo does work.

6 Comments

Filed under Uncategorized