On Wed, Oct 7, 2009 at 11:09 AM, Peter Tyser <pty...@xes-inc.com> wrote: > On Tue, 2009-10-06 at 18:43 -0500, Peter Tyser wrote: >> > > The values all changed and are dependent on RAM size, but their >> > > relationship to one another didn't - they all just increased by >> > > 0x7fff0000. So practically speaking, we do need to know where the bss >> > > is at link time - its address is not dynamic like the malloc pool or >> > > stack - its tied directly to the address of the other sections at link >> > > time. (Unless we added some bss-specific fixups I imagine) >> > >> > Right, that's the current situation. >> > >> > My suggestion was NOT to put the bss at a fixed _offset_ to the >> > U-Boot image, but to a fixed absolute address. My hope is that this >> > might simplify the linker scripts at the cost of adding a little code >> > to the relocation routine - for addresses in the bss we would have to >> > add a different relocation offset. >> >> I think I see what you're getting at. If we have a bss-specific fixup >> routine I don't give a hoot where the bss is located at link time. Its >> just that that bss-aware fixup routine doesn't exist right now:) >> >> It seems like a clean solution. Adding a bss-aware fixup routine or >> putting the bss after the U-Boot image both seem good to me. The >> bss-aware fixup routine has a clearer readelf output and slightly more >> complicated code while the bss-after-uboot change has a misleading >> readelf output and simpler code. In any case I'd give a thumbs up to >> either of them. > > Sorry, just to be clear, where did you want to put the fixed up bss? > Still at a low memory address, ie the original address at link time? I > had assumed if we were adding a bss-specific fixup we'd move it to the > top of memory, near U-Boot, the malloc pool, etc. I'd be all for > relocating it to higher in memory, but wouldn't be too excited about > leaving at a low memory address... If we were to add bss fixups, we may > as well move it to a location that lines up with the rest of U-Boot > code, stack, and malloc, right? > > Best, > Peter >
The longer this thread goes on, the more obvious it becomes to me that a basic dynamic loader which is 'ELF Aware' will overcome most (if not ultimately all) of the problems being discussed in relation to relocation. I have a proof-of-concept for this (written entirely in C) which I needed to create due to the lack of a .fixup section on my arch (a limitation of all but one arch to date). More to the point, the information regarding the content of the ELF sections I was able to find wasn't even for the target arch I wrote the code for - It is all very generic (to a point). I think that even the -mrelocatable / .fixup method may not be needed at all. -pie / -pic used by themselves creates enough information for an OS dynamic loader to relocate an executable, so why not U-Boot? Given that the type and location of each section is easily determined, a striped down dynamic loader can provide a platform-independent relocation scheme. I believe that relocation for all arches, and thus the permanent removal of all the relocation fix ups littering the code, can be achieved far quicker this way. Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
