@knc1, as you've collected some cross-compiling toolchains in scope of KeK project, you might be interested in The Embedded LLVM Compiler Collection: ellcc.

It's a cross-compilation environment based on Clang (which is modern C/C++ compiler using LLVM infrastructure). ELLCC has support of compiling for Linux and includes ARM as cross-compilation target (amongst many other targets). Building and installation from sources is as easy as svn co ... && ./configure && make && make install and there are also pre-built binaries for Linux x86-64.

It doesn't include (e)glibc/libstdc++, it incorporates musl and libc++. But it could be seen as advantage for static builds

@eureka: Oooh, good to know, I wasn't aware of musl, and that there was something like that using an x-clang tc . (clang's veeeery nice. If you've never checked it out, even on a native system, do so. The static code analysis tools and address sanitizer introduced in 3.1 are pretty nice features, especially compared to the mess that is setting up/using valgrind on a recent distro...)

@eureka: Oooh, good to know, I wasn't aware of musl, and that there was something like that using an x-clang tc . (clang's veeeery nice. If you've never checked it out, even on a native system, do so. The static code analysis tools and address sanitizer introduced in 3.1 are petty nice features, especially compared to the mess that is setting up/using valgrind on a recent distro...)

Well, I did use Clang for some native builds and have an interest in using it for cross-compiling (I didn't use ELLCC just because I already have Clang installed and have an urge to adapt this installation for cross-compiling needs). Seconding your promotion.

It might be worth checking if the mentioned patches are already in our qemu sources before starting to follow that article. Mainstream may have picked them up but implemented the features a bit differently.

Edit:
One point you will not find in the general articles . . .
The i.MX Freescale SoC has a hardware watchdog which can not be disabled and if not serviced, will reset the core.

So any program running in control of the processor (iBootloader, U-boot, kernel in that order) has to provide code to service the watchdog often enough to keep it from tripping.

Things may not be the same under emulation - I don't know if qemu emulates the non-maskable hardware watchdog.

Running within the emulator, our /mnt/hdb2 location is known as /home.
Make the emd sub-directory and populate it with the Ubuntu-core files:
These two steps MUST be done as 'root' to get the image correct!

To make up for that lack, move the swap file inside of the chroot tree.
It would be better to leave it where it is and start it before doing the
following tmpfs assignments but that would take building swapon/swapoff.

Well, this bright idea isn't going to work as-is.
Need to (at least) build swapon/swapoff/chroot for the emulation environment.
Once that is done, then this method should work for (e)glibc development.

@knc1 Hmm yes - do you think this may go some way to explain my experiences with the internal 'ar' etc. Well. I shall resume cheerleading - bloody good catch mate.

Intrigued to know the result mate.

ra ra emu!

I recall your reporting programs that did that and yes, it may be related.

The 'main' executable code of /bin/true (or /bin/false) should be two machine instructions. One to set the register holding the returned value and the "return" instruction itself. Neither directly accesses memory (not even in RISC).

But every compiler generated executable contains a preamble and a post-amble (setting stack pointer, saving the return address, +a bunch of other things). Most of those involve setting registers to point at the proper parts of memory.

Those, if using a register that wasn't set to the expected value, or not set at all, can cause a memory segmentation violation.

There have been various "ABI"s for ARM over the years, Rob's compiler may be set to generate one (the compiler generated pre/post ambles) and the Ubuntu-core man be using another (with different register usage defines).

It will take a bit of research and maybe some disassembly to identify where the mismatch is originating.

Although in the end, it may be time to replace Rob's rootfs that we are using.
For new work, with one of the Ubuntu-core rootfs images.
For Kindle re-work, by adding a native tool-chain to the one you just built against the Amazon kernel.

Hmm...
Maybe the fasted way forward is to just get the emulator to boot these other rootfs images.