From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id C5A843857C5B for ; Tue, 5 Jan 2021 09:58:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C5A843857C5B Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-475-ohHacIbVNd6i0eRag-ff8Q-1; Tue, 05 Jan 2021 04:58:10 -0500 X-MC-Unique: ohHacIbVNd6i0eRag-ff8Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A1CB615724; Tue, 5 Jan 2021 09:58:08 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-120.ams2.redhat.com [10.36.112.120]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EF75310016FE; Tue, 5 Jan 2021 09:58:07 +0000 (UTC) From: Florian Weimer To: Fengkai Sun via Libc-help Cc: Fengkai Sun Subject: Re: Is writing a dynamic linker/loader to load glibc a bad idea? References: Date: Tue, 05 Jan 2021 10:58:06 +0100 In-Reply-To: (Fengkai Sun via Libc-help's message of "Tue, 5 Jan 2021 11:25:04 +0800") Message-ID: <87ble3hfip.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 09:58:14 -0000 * Fengkai Sun via Libc-help: > Sorry in advance if this question is a bit unclear and confusing. > > Recently I want to implement an ld.so myself, that is, a DSO that allows me > to load other DSOs into memory. > > I've tried my best to finish all the steps that I discovered: loading > PT_LOAD segments with mmap, loading dependencies, relocating, and calling > DT_INIT and DT_INITARRAY in the right order. > > It works all right when the DSO is simple, e.g. using a few printfs and > other libc functions. But it fails when I'm using some(not all) DSOs in the > real world. At present, this isn't really possible because among other things, the dynamic loader needs to provide the _rtld_global and and _rtld_global_ro variable to libc.so.6, and the layout of these variables changes fairly rapidly. glibc's ld.so also knows about unusal initialization requirements for libc.so.6 (see __libc_early_init, _dl_var_init). It may be interesting to come up with the absolut minimum set of ld.so interfaces, and try to move the rest into libc.so.6, and then stabilize the interface between the two. But today, glibc's hooking mechanism for ld.so is the audit (LD_AUDIT) interface, not replacing ld.so completely. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill