public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Fengkai Sun <qcloud1014@gmail.com>
To: libc-help@sourceware.org
Subject: Enable preloading in dlopen-ed shared libraries?
Date: Wed, 14 Jul 2021 16:44:12 +0800	[thread overview]
Message-ID: <CAF6YOcO=rm2THiDh-VAa-V23jnWrZU2DcrSk5g4C=k3H9fL8Xg@mail.gmail.com> (raw)

Hi list,

As I dive a little deeper into the source code, I found that
`_dl_map_object_deps' is called in both rtld.c and dl-open.c.

The semantics of two invocations are both clear: rtld.c makes a call like
this:
_dl_map_object_deps (main_map, preloads, npreloads, mode == trace, 0);
because ld.so needs to preload the libraries specified by LD_PRELOAD into
the global scope for interposing the symbols.

dl-open.c makes a call like this:
_dl_map_object_deps (new, NULL, 0, 0,
      mode & (__RTLD_DLOPEN | RTLD_DEEPBIND | __RTLD_AUDIT));
because no dlopen-ed library needs to preload anything.

However, I think it might be useful to allow users to preload some
libraries in the local scope after the map of the dlopen-ed library, just
like how ld.so treats preloaded libs in global scope.

By doing so, the user can easily provide a different definition of a symbol
from the one of the main executable, by enabling RTLD_DEEPBIND.
This is useful under some circumstances. For example, a dlopen-ed library
may want to use a separate heap from the main heap, and the user can
provide another malloc implementation for that library.

The auditing interface can do the similar thing, but after doing some
experiments, I found that `la_symbind64' cannot catch the bindings of
global variables, and it cannot hook all of the function bindings.

Would it be a good idea to add an interface to enable preloading in the
local scope of dlopen-ed shared libraries?

Thank you in advance.

--
Best,
Fengkai

             reply	other threads:[~2021-07-14  8:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14  8:44 Fengkai Sun [this message]
2021-07-23 21:00 ` Adhemerval Zanella
2021-07-24  2:51   ` Fengkai Sun
2021-07-26 19:51     ` Adhemerval Zanella
2021-07-27 13:23       ` Vivek Das Mohapatra
2021-07-28  6:17       ` Fengkai Sun
2021-07-28 18:09         ` Adhemerval Zanella
2021-07-28 19:02           ` Geoff T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF6YOcO=rm2THiDh-VAa-V23jnWrZU2DcrSk5g4C=k3H9fL8Xg@mail.gmail.com' \
    --to=qcloud1014@gmail.com \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).