Haavard Skinnemoen wrote: > 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. > That is the entire loadable image. The percentage will therefore be slightly higher as a function of just the .text section. It is pretty representative of the effect though. On the "old beast", it is not so good! > > >> 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. > You are correct. The contents of initialized pointers are not relocated without using the relocation data provided by -pie on the ld script. > >> 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. > I agree completely. Now we "just" need to add processing the relocation data. Also, the relocation vectors differ in contents from platform to platform, so a bit of "custom" processing will be needed for each architecture.
Bill Campbell > 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
