On Wed, Oct 7, 2009 at 11:09 AM, Peter Tyser ptyser@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