What might be ideal then, are backported *cross* gcc-5, binutils etc. packaged up in a jessie chroot, so that ":armhf" versions of build dependencies (the same versions as those on the Pyra) can be installed using multiarch. I'll have some free time in a couple of weeks to attempt this and will be happy to put together some instructions and share the result.
When connected to a a USB host then it (the internal UART<--->USB bridge) presents itself as an RS232 serial adapter (from wikipedia):
Class Usage Description Examples, or exception
00h Device Unspecified Device class is unspecified, interface descriptors
are used to determine needed drivers
01h Interface Audio Speaker, microphone, sound card, MIDI
02h Both Communications Modem, Ethernet adapter, Wi-Fi adapter,
and CDC Control RS232 serial adapter. Used together with class 0Ah (below)
So that in the computer you could open use a terminal to see/interact with the Pyra via the serial interface.
In theory it would be possible to use one micro-B to A USB cable to connect the debug port of one Pyra to the fullsize USB host port on another Pyra.
Then another cable would be required for the back connection. And then both pyras would try to charge each other endlessly (wasting power instead).
TL DR; It's actually Serial over USB, not a pure RS232 serial port.
Ok, was easier than expected to get at least a "Hello World!\n" build(have to wait for HW to test it ...*freu*).
Installed on debian every thing according to https://wiki.debian.org/CrossToolchains#For_jessie_.28Debian_8.29 and the used arm-linux-gnueabihf-gcc to compile the main.c. The result is a file that should run on a ARM device according to 'file a.out'. For more serious stuff, e.g. compiling kernel and stuff I'll have to play around a bit. If that works I'll try a newer GCC version or LLVM/CLang.
Hm ... I can try to compile for mi RaspPi and see if it works there and if so, only the compiler has to be changed..., but not today.
You could test your compiled binaries in a Qemu VM. Among others, Qemu can emulate a Cortex A15, which will be used in the Pyra. This would be much closer in terms of CPU features than running it natively on a Raspberry Pi (1st gen.).
Qemu comes with a huge performance penalty though, when emulating foreign architectures. So I wouldn't recommend to compile in the VM directly. And you shouldn't make performance judgements based on what you see in the VM.