You should switch to GCC 4.6.2, lkj: all "x.y.0" releases of GCC contain quite a few significant bugs
(though the last major disaster "x.y.0" release was GCC 4.0.0, i.e. years ago)

Could somebody quickly check my code, it doesn't seem to print the value of f. Either I'm using nl_relocdata wrong, or then I'm too tired and am missing something silly.

http://pastebin.com/N2iiUhd1

That's more or less how SDL behaves at one point, and it's reallocating the function pointer that causes issues. The strings print out fine, calling the function doesn't work though.

EDIT: I've tried everything I can think of. Am I really missing something here or is there no way to use nl_relocdata on a pointer to a function? (I doubt it, even in the wiki it is mentioned)

Thanks, but it unfortunately did not fix it. What exactly does size refer to--what size does it refer to (in bytes I presume)? I'll experiment around a bit, but if there is no solution yet I will kindly wait for any future developments.

EDIT:
What do you mean relocating NULL? bootstrap is not NULL, nor is the quotient equal to zero.

Hmm... how hard will it be to write a BLFT loader? It seems that this project (and possibly many others) might need one.
It has code relocation and is much smaller than the ELF loader.

(If it isn't too hard, I might attempt to write one Seems that one would need to know ARM ASM to do it... which I don't know)

I have indeed started looking at what pieces need to be changed for porting Linux's bFLT loader (fs/binfmt_flat.c + include/linux/flat.h + arch/arm/include/asm/flat.h) to non-Linux OS running on the Nspire. And a quick examination (<1h) shows dozens of places that need to be adjusted; it's not necessarily very hard to do so, for the most part, it's just that someone needs to spend time doing it, and I don't have time to undertake such a task alone - for a start, not this evening.

ExtendeD has suggested looking at QEMU's loader (linux-user/flatload.c), which looks slightly more portable than Linux's loader. It remains quite tied to Linux/QEMU internals, and may or may not be a better starting point than Linux's loader: unlike Linux's loader, QEMU's loader's support for compressed binaries and for libraries is explicitly disabled - and we clearly want both, probably with a higher priority on libraries. Support for compressed bFLT binaries wouldn't cost much space in the loader, since we can (well, "ought to be able to") rely on the zlib functions embedded in the OS.

Seems that one would need to know ARM ASM to do it

I doubt that it's necessary: AFAICT, the bFLT loaders in Linux and QEMU are plain C


EDIT: here's the current state of the stuff. As you can see, I haven't changed the code yet, and won't do tonight. The tarball is made of five files:
* binfmt_flat_mod.c is Linux's bFLT loader, annotated with a bunch of TODOs on parts that we need to remove or port;
* binflt_flat.diff is the diff against the pristine file;
* the two headers are include/linux/flat.h and arch/arm/include/asm/flat.h;
* flatload.c is QEMU's bFLT loader.

Oh wow, thanks. I'm quite surprised as I tried the same code as you except without the &-operator; I thought prefixing a function name with the ampersand was optional, both should return the address of the said function AFAIK.

EDIT:
This is great news as I'm now able to initialize the barebone video driver:

Good

Here the address of the field that contains the function pointer is expected, so the & is required.

Good to hear hoffa. Hopefully this gets finished eventually.