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
