From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14371 invoked by alias); 17 Jun 2019 18:55:52 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 14354 invoked by uid 89); 17 Jun 2019 18:55:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=route, the, the=c2, c3?= X-HELO: mail-wr1-f43.google.com Received: from mail-wr1-f43.google.com (HELO mail-wr1-f43.google.com) (209.85.221.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jun 2019 18:55:50 +0000 Received: by mail-wr1-f43.google.com with SMTP id r16so11139145wrl.11 for ; Mon, 17 Jun 2019 11:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=02hO10uIfO0E+QH35qW7ohT+P2N7IM21Z717XPJqSyM=; b=TMtzLaVaGjgg3IQn49tszYetoe8EkOGCQVpeFggyNJwqFSQHfqntinfXcUi/C6LVkw TwOjgMTKDr7jrfC+PuLrLtPCqPrimaTh25Q7zI4F6Qt8Fof3fMJrPK+bT9F5iorcVGqm LCFf/ApbN2vNfM0wli7aJUNd+l9Kq2vVQnDeW8DoLwxgCZHzQVN5GIgYwK/4MCjAXbED Cw+scBLgNN4t93Za1ZHoxdFusPTIy9wmo+L87jYaurDfP/jLSni6PR29yPfJ27kO6woz t7cf9iJvovYDo5/UJNdyr23mHlSC+SDlbaVQpbHS4IkNfaarZUyUuDLnAMh4s41YH3WQ r4jw== MIME-Version: 1.0 References: <871rzsdpj5.fsf@oldenburg2.str.redhat.com> In-Reply-To: <871rzsdpj5.fsf@oldenburg2.str.redhat.com> From: Baojun Wang Date: Mon, 17 Jun 2019 18:55:00 -0000 Message-ID: Subject: Re: dlmopen in LD_PRELOAD To: Florian Weimer Cc: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00031.txt.bz2 > 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 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 >