Re: [PATCH] ppc64 LD_PRELOAD tolerance

["Steve Munroe" <sjmunroe at us dot ibm dot com>]

Roland McGrath writes:

> If there is no 64-bit version of the preload module available, then
having
> 64-bit programs silently ignore their setting and behave as they are used
> to 32-bit programs behaving only without their preload, is not what users
> are expecting.

That is a valid concern, but I have an equally valid concern. What if a
user is happily using his 64-bit applications but finds a neat 32-bit tool.
After installing this tool none of his 64-bit applications will not run!
Because that 32-bit tool added a path qualified entry to LD_PRELOAD. I
don't think users are expecting that either.

If may be valid to only have a 32-bit (or 64-bit) version of a specific
preloaded module. This can happen because the preload in only intended for
32-bit (or 64-bit) applications. Or and more likely that developer has only
has access to 32-bit systems and does not know about these issues or never
imagined that any one on a 64-bit system would want his tool.

> For specifying preloads by explicit file name, so as to use ones not in
the
> standard search path or avoid searching for some reason, what seems most
> useful is a way to specify you want split 32/64-bit variants so that one
> LD_PRELOAD setting can work for both 32-bit and 64-bit programs (as
> e.g. one LD_LIBRARY_PATH setting will work because of the skipping
behavior).
> I've added (not checked in yet) a simple feature for this in the form of
a new
> dynamic string tag $LIB that expands to either "lib" or "lib64".  So you
can
> use LD_PRELOAD='/$LIB/libfoo.so' or LD_PRELOAD='/my/foo${LIB}.so' to find
> /lib64/libfoo.so or /lib/libfoo.so and /my/foolib64.so or /my/foolib.so.

This is an interesting proposal but I think it requires recognition.
Developers of 32-bit application packages have to know that they should
have used /x/lib/my.so paths all along. It also seems to require that each
preloaded library will have both 32- and 64-bit libraries. Otherwise the
problem above still exists. The the current environment most packages will
only exist for 32-bit. We assume this will change over time, for those
packages that need and can take advantage of 64-bit address spaces.

Perhaps some addition dynamic symbols can improve this. For example
($LIB32)my.so indicates explicitly that my.so only exists for 32-bit and
should be ignored for 64-bit. Of ($skip64)my.so could be added to the end
of the LD_PRELOAD string to recover from the first scenario.

For this to work we should need some better (then "cannot open shared
object file xyz") error messages. For example: "Shared object xyz was
specified for PRELOAD but a [32-|64-]bit version could not be found".