public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Baojun Wang <wangbj@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-help@sourceware.org
Subject: Re: dlmopen in LD_PRELOAD
Date: Mon, 17 Jun 2019 18:58:00 -0000	[thread overview]
Message-ID: <CAC+a-TYxMZ=3jbSZbMNm0229onbVEz0wCGi1nNQRkSfKxJLg=w@mail.gmail.com> (raw)
In-Reply-To: <CAC+a-TZVh9NMjzMLuZ73bSHKhu8gGcpiAJ2HCZoZON3tOJs5Tg@mail.gmail.com>

 I can  => I cannot

On Mon, Jun 17, 2019 at 2:55 PM Baojun Wang <wangbj@gmail.com> wrote:

> > Does the library you load via dlmopen contain its own definition of
> malloc, perhaps indirectly?
>
> I don't think so, though the dynamic library does depends on libc.so. To
> elaborate, the dynamic library is a rust `cdylib` (`.so`),
> rust use system malloc by default, however, rust does use TLS quite
> extensively. glibc's malloc uses TLS by default, seems even
> malloc-experimental disabled during configure phase.
>
> Maybe `LD_PRELOAD` a customized `libmalloc.so` (without using TLS) could
> be an option, though I wouldn't like the idea because malloc itself exports
> quite a lot symbols, and the
> additional efforts of having to maintain the hacky `libmalloc.so`. Using
> exactly the same glibc is a huge plus and I'd really like to stick will
> this route.
>
> Also worth mentioning is if I manually patch `__get_nprocs`, which is
> called `area_get2`, then I can see the stack overflow any longer. the
> pseudo assembly used to patch `__get_nprocs`:
>
> /*
>
> __libc_get_nprocs:
>
>    0:   b8 02 00 00 00          mov    $0x2,%eax
>
>    5:   c3                      retq
>
> */
>
> Thanks
> Baojun
>
>
> On Mon, Jun 17, 2019 at 2:40 PM Florian Weimer <fweimer@redhat.com> wrote:
>
>> * Baojun Wang:
>>
>> > Can `dlmopen` be called in a DSO being `LD_PRELOAD`-ed? The idea is to
>> > create a minimal DSO used for `LD_PRELOAD`, then inside the DSO
>> > (.init_array), call `dlmopen` to open the DSO that I'm really interested
>> > in. hence the DSO being `LD_PRELOAD` acts like a mini loader only.
>> >
>> > I did exactly above, but ran into issue (segfault) with stack overflow:
>>
>> Does the library you load via dlmopen contain its own definition of
>> malloc, perhaps indirectly?
>>
>> I expect what happens that with regular LD_PRELOAD, its TLS usage gets
>> promoted to the static TLS allocation, which is allocated by the dynamic
>> loader by the bootstrap/minimal malloc.  With the indirection through
>> dlmopen, dynamic TLS will be allocated with malloc, which does not work
>> if malloc itself uses dynamic TLS.  You can try to build that malloc
>> with initial-exec TLS, but dlmopen'ing that could then fail because the
>> static TLS reserve could be exhausted.
>>
>> Thanks,
>> Florian
>>
>

  reply	other threads:[~2019-06-17 18:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-17 18:06 Baojun Wang
2019-06-17 18:40 ` Florian Weimer
2019-06-17 18:55   ` Baojun Wang
2019-06-17 18:58     ` Baojun Wang [this message]
2019-06-17 19:02     ` Florian Weimer
2019-06-18  4:15       ` Baojun Wang
2019-06-21 11:53         ` Florian Weimer
2019-06-21 14:11           ` Baojun Wang
2019-06-21 16:11             ` Florian Weimer
2019-06-21 20:23               ` Baojun Wang
2019-07-04 13:22                 ` Florian Weimer
2019-07-05 18:21         ` Florian Weimer
2019-07-05 18:26           ` Baojun Wang

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='CAC+a-TYxMZ=3jbSZbMNm0229onbVEz0wCGi1nNQRkSfKxJLg=w@mail.gmail.com' \
    --to=wangbj@gmail.com \
    --cc=fweimer@redhat.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).