[PATCH 1/2] elf loader support for auxvec base platform string

[Benjamin Herrenschmidt]

Adding Steve to the CC list as I'd like his input from the
glibc/powerpc side as he's the requester of that feature in the first
place.

Steve: Roland is proposing to ues dsocaps instead of AT_BASE_PLATFORM.

Cheers,
Ben.

On Mon, 2008-07-07 at 17:31 -0700, Roland McGrath wrote:
> > > The kernel does not have to come from the same place as the root
> > > filesystem.  You may want to run a new kernel with an old filesystem, or
> > > vice-versa.
> 
> Well, it's not like these bits are really going to change in practice.  My
> point was just that this is a far "softer" ABI than the general kernel-user
> contract.  Sorry if my being precise about things gives you indigestion.
> 
> > I agree, I'm pretty dubious here...
> 
> Dubious about whether the dsocaps bit assignments are "part of the ABI"?
> Fine.  Let's talk again when you've used up 32 bits and want to figure out
> what to do next.
> 
> Dubious about whether dsocaps is the right thing to do?  I think you are
> overlooking what the actual kernel-user compatibility reality is here.
> 
> Firstly, what is the "risk" in the "gone wrong" case?  The risk is that a
> DSO load via ld.so.cache will overlook a /lib/power99/foo.so match and get
> a /lib/foo.so match instead because ldconfig doesn't know about "power99".
> If foo.so wasn't in ld.so.cache at all, there is no problem.
> If you used LD_LIBRARY_PATH, there is no problem.
> If you used dlopen with an explicit file name (has /), there is no problem.
> 
> What happens if you boot a kernel that uses dsocaps with the new string
> "power99", but you are missing the ld.so.conf.d file to match your kernel?
> Then a DSO load via ld.so.cache will overlook "power99" matches.
> 
> How do you fix it?
> Install the right (tiny text) file, and run ldconfig.
> 
> What happens now if you are using a new kernel that supplies a new string
> "power99" in AT_PLATFORM or another auxv element used the same way, but
> with an old root filesystem (say one including any glibc that exists today)?
> Then a DSO load via ld.so.cache will overlook "power99" matches.
> 
> How do you fix it?
> You add a bit assignment in the glibc sources, recompile glibc,
> install a new whole glibc package.  (Conceivably if you are extremely
> careful you can manage to redo an otherwise completely identical
> build to the glibc on your old system and replace only ld{64,}.so.1
> and ldconfig.)  Then run the new ldconfig.
> 
> In short, if you use a root filesystem from before kernels started using
> the new string, then you will degenerate to default-platform library
> matches from loads via ld.so.cache (i.e. /lib/foo.so, not /lib/somecpu/foo.so).
> If you want to do better than that for this case, it's intractable using
> AT_PLATFORM, and simple using dsocaps (probably simpler than booting a
> special kernel was).
> 
> I haven't figured out what in this old-vs-new picture you think AT_PLATFORM
> or something else like it would ever buy you.
> 
> 
> Thanks,
> Roland
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/