On Sat, 26 Jul 2008 14:29:35 -0700 "J. William Campbell" <[EMAIL PROTECTED]> wrote: > Haavard Skinnemoen wrote: > > On Fri, 25 Jul 2008 22:51:09 +0200 > > kenneth johansson <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
