Hi,
On Wednesday 03 February 2010 08:54:04 Mike Frysinger wrote:
> i'm assuming this is a nommu system (i.e. no virtual memory), else FDPIC is
> kind of silly. doing standard ELF makes more sense when you have virtual
> memory.
Of course, it's nommu.
> i wonder why you didnt just go with FLAT/shared FLAT to start with ...
I'll give you some more background.
We use the open source LatticeMico32 soft-processor, made by Lattice
Semiconductor, who contracted Theobroma Systems to do the uClinux port [1].
We re-used this port, but Theobroma didn't really do a good job, with
gazillions of problems in the kernel (that we managed to fix ourselves, i.e.
me and another contributor), and, more importantly, in the executable loader.
Their executable loader is based on FDPIC and comes in two "versions":
* the default version is the "crap" I was talking about in my initial e-mail.
You use -Wl,-q during linking, then you are careful that you do not strip the
emitted relocations, and then, a modified kernel loader will patch the
instructions at runtime according to the relocation table. This version
somehow works. Theobroma calls it "production grade" [2].
* it seems they tried to use normal FDPIC but they failed. A patch is lying
around in their source distribution that reverts the modifications made to the
kernel loader and also patches uClibc's relocation code and the
compiler/linker flags. This version does not work at all because they made
mistakes such as [3] and maybe others.
My idea was to use FDPIC because we already have bits of the loader and also
because there is already a FDPIC-based target in the OpenWrt distribution.
Another problem we might have with FLAT is that the relocations are always 32-
bit addresses, and LatticeMico32 loads 32-bit immediate values with two
instructions (load high + load low, each 16-bit), making the implementation
rather tricky.
> latest uClibc already supports FDPIC. simply look at the blackfin
> g'luck ... this port isnt going to be quick :P
It would be if you wouldn't have to crawl through millions of disgusting and
undocumented lines of code puked out by bearded GNU hippies high on acid
whenever it comes to modifying or just understanding GCC. GNU seems to take a
particular attention to violating all good programming wisdom. Where is the
document called "Adding a new ABI to the GNU toolchain"? Executable loaders
are no big deal, only GNU and the lack of documentation make them so.
That being said, the problem with the LM32 loader still needs to be solved.
Contrary to Milkymist/LM32, the Blackfin that you mentioned is a proprietary
and closed CPU. But it has an outstanding uClinux port with good documentation
and I will attribute that to corporate sponsorship of the "Koop". I'm nowhere
near as rich as Analog Devices, but how much would you charge for fixing
Theobroma's FDPIC loader and its environment (toolchain, uClibc, etc.)?
Sébastien
[1] http://www.theobroma-systems.com/uclinux-lm32/
[2] http://www.theobroma-
systems.com/assets/downloads/mico32/Lattice_FCS_Release_20071130.pdf
[3] http://sourceware.org/ml/binutils/2007-03/msg00422.html
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
