From mboxrd@z Thu Jan 1 00:00:00 1970 From: Haavard Skinnemoen Date: Sat, 26 Jul 2008 23:58:18 +0200 Subject: [U-Boot-Users] Changing u-boot relocation scheme In-Reply-To: <488B973F.8020609@comcast.net> References: <20080724185734.6d79c419@hskinnemo-gx745.norway.atmel.com> <20080725042816.4F8B1248A5@gemini.denx.de> <20080725111041.4c0b925a@siona.local> <1216986958.17719.13.camel@duo> <20080725141909.4a635af0@siona.local> <1216996436.7972.14.camel@duo> <20080725172334.13ee6301@siona.local> <1217003489.7972.33.camel@duo> <488A0729.1070306@ge.com> <1217006928.7972.47.camel@duo> <20080725203517.2b940103@siona.local> <1217019069.7972.58.camel@duo> <20080726175454.17a14a97@siona.local> <488B973F.8020609@comcast.net> Message-ID: <20080726235818.3aee9d34@siona.local> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, 26 Jul 2008 14:29:35 -0700 "J. William Campbell" wrote: > Haavard Skinnemoen wrote: > > On Fri, 25 Jul 2008 22:51:09 +0200 > > kenneth johansson wrote: > >> Can't see any reason for using this flag over -fPIC for a program like > >> u-boot. > >> > > > > You need both. One is a compiler flag, the other is a linker flag. The > > linker will probably barf if you try to create a PIC executable from > > modules that were not compiled with -fPIC. > > > No, it won't. On some platforms it will. Text relocations are nasty, so some platforms (e.g. avr32) just refuse to deal with them. But that's not really relevant -- each architecture should decide whether to compile with -fPIC or not. > You just get a module with a lot more relocations to do. I > have verified that all four possible combinations of the compiler -fPIC > and linker -pie work and make sense. FWIW, -fPIC code on IA32 is about > 16% larger than non-PIC code, while on the Blackfin, -fPIC code is about > 2% larger than non-PIC code. This is an average over several large C++ > applications. Right...that's counting the whole loadable image or just the .text section? Not suprising that a modern architecture like Blackfin likes -fPIC a lot better than an old beast like i386 though. > I agree with this suggestion. This is the only way to ensure a "sane" > environment, because it emulates what the compiler expects to happen. > Looping over all the relocation entries and doing the "right thing" is > architecture specific, but the process is general. The GOT entries can > also be processed this way. Effort spent on this approach will tend to > be more generic than the current PPC specific approach. Right...I think the GOT entries already are processed this way, sort of. > > Ah, of course. The strings are probably read directly from flash. > > > Maybe not. I have been looking at assembly dumps of short examples on > the IA32 built with -fPIC. It is clear that the method of addressing > static variables and static constants is DIFFERENT from the method used > for global variables. The relationship of the location of the text > segment (executable code), the GOT data, and the static > variables/constants must remain fixed. The location of the entire > program can move, but it must move in one piece. If it does move as one > piece, the lea (load effective address) instructions relative to the GOT > pointer will be relocated to the new address correctly. These references > are based totally on the offset from the point of reference. If the code > is similar on your platform (which I bet it is), then the reference will > not be to the flash but rather the "new" place where the data was > moved.. Yes, address calculations in the code should be correct, as the whole thing was compiled with -fPIC. Data references, however, are usually not. The code being discussed here is an array of pointers to strings. I'm pretty sure the pointers are still pointing to flash after relocation. > Global variables, however are referenced indirectly via 32 bit > address pointers in the GOT, and these addresses must be relocated by > the "loader". The global variables themselves are accessed through the GOT, yes. But the _value_ of a global variable is currently not relocated automatically. > The "loader" also must relocate any initialized pointers, because the > program itself does not. It would be interesting to know how this is > accomplished, via what relocation codes, but it does happen. This is what's currently being done manually by adding a fixed offset to all the pointers we "know" need to be relocated. When linking with -pie, these initialized pointers will get a dynamic relocation entry each so that we can replace all these manual fixups by simply iterating over the relocations. To summarize: Address calculations in executable code do not need to change since we already compile with -fPIC. Initialized pointers, however, are currently handled in a very suboptimal way, and linking with -pie might be one piece of the solution to this. Haavard