Hi Mike,
On Wed, Nov 9, 2011 at 12:46 AM, Mike Frysinger vapier@gentoo.org wrote:
On Tuesday 08 November 2011 02:08:42 Gabe Black wrote:
This change adds an upper bound for symbols which are fixed up after u-boot is relocated into RAM. This way portions that are left at their original location can be referred to without having to manually fix up any pointers.
i'm not familiar with the u-boot relocation handling on x86, but if a symbol shouldn't be relocated, then why does it have an elf reloc ? shouldn't it be an absolute symbol ?
As Gabe pointed out, all x86 source files are compiled with the same options (i.e. with relocation enabled). This includes the 16-bit realmode sections which are actually designed to run at a fixed location in memory. Now this introduces a few issues:
a) There are entries in the relocation table that point to relocations in lower memory (i.e. below TEXT_BASE) - That's the first test b) Where the 32-bit bit code transitions to 16-bit, there is a relocation entry which points to a location above TEXT_BASE, but because the jump is to a fixed location in memory (below TEXT_BASE) it must not be adjusted (this is the second test)
There is also a couple of relocations that do not need adjusting in the reset vector code and real-to-protected mode switch, but these are a don't care case because by that stage, the code has already been run and will not be run again so it really does not matter what we do to them
Now I think we might be able to compile the 16-bit code without relocations (would need to tweak how the compiler flags are handled and split them up a bit) and also change the 32-to-16 bit jump so it does not get a relocation entry (I think I have a patch somewhere already as part of my massive 32-to-16 bit switch change) so we might be able to get rid of both test at some stage...
Regards,
Graeme