On Sep 26, 2007, at 6:25 PM, Paul Mackerras wrote: > Since about May 2001, we have put two AT_IGNOREPPC entries at the > beginning of the ELF auxiliary vector. The reason for this is that > glibc prior to April 2001 rounded up the address of the base of the > aux vector to a multiple of 16. I think we can now get rid of the > AT_IGNOREPPC entries. > > Well, in fact what old glibc did was a little more complex than that. > It worked out the standard aux vector base (i.e. the address of the > word after the end of the environment pointers), and then chose either > that or that address rounded up to a multiple of 16 bytes. The way it > chose was by checking the word at the rounded address - if it was more > than 16 it used the standard base address, otherwise it used the > rounded address. > > So the way the AT_IGNOREPPC hack worked was by putting 4 words (two > aux vector entries) at the beginning of the aux vector that all > contained the value 22 (AT_IGNOREPPC). That made the old glibc code > choose the standard aux vector base address. > > However, what comes after that is an AT_DCACHEBSIZE (19) entry and an > AT_ICACHEBSIZE (20) entry. Thus, as long as the data cache blocksize > and the instruction cache blocksize are greater than 16, these two > entries will serve just as well as the AT_IGNOREPPC entries at making > old glibc choose the standard aux vector base address. > > The only CPUs that we support with cache line sizes of 16 bytes or > less are the 8xx family and the 403 family. So my question is, does > anyone care about running ancient userland binaries (from 2001 or > earlier) on 8xx or 403 with future kernels (2.6.x for x >= 24)? > > If not then we can remove the AT_IGNOREPPC aux vector entries.
What's the benefit to removing them? - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
