really old glibc on 8xx or 403 with bleeding-edge kernel - anyone care?
galak at kernel.crashing.org
Thu Sep 27 20:12:38 EST 2007
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?
More information about the Linuxppc-dev