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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 79168385802E for ; Mon, 1 Mar 2021 09:42:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 79168385802E 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-378-gS2Bn6VwPbGfEuKyXGfO_A-1; Mon, 01 Mar 2021 04:42:46 -0500 X-MC-Unique: gS2Bn6VwPbGfEuKyXGfO_A-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 043E91868408 for ; Mon, 1 Mar 2021 09:42:46 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-131.ams2.redhat.com [10.36.113.131]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 58FA86BF6B for ; Mon, 1 Mar 2021 09:42:45 +0000 (UTC) From: Florian Weimer To: libc-alpha@sourceware.org Subject: Re: [PATCH] Reduce the statically linked startup code [BZ #23323] References: <87lfblmsez.fsf@oldenburg.str.redhat.com> <874ki0m13w.fsf@oldenburg.str.redhat.com> Date: Mon, 01 Mar 2021 10:43:40 +0100 In-Reply-To: (Mike Frysinger's message of "Sun, 28 Feb 2021 01:02:37 -0500") Message-ID: <87zgzni4z7.fsf@oldenburg.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.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.6 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_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no 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-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 09:42:52 -0000 * Mike Frysinger: >> What about this? >> >> /* Note: This file is part of the startup code in statically linked >> programs. From the statically linked startup code, dynamically >> linked programs call __libc_start_main in libc.so, which is compiled >> from this file as well, but not part of the statically linked startup >> code due to this separation. */ > > iiuc, libc-start ends up in libc.a & libc.so. in both cases, it provides > the __libc_start_main symbol, and in both cases, the crt object calls it. > > when you say "statically linked startup code", i'm guessing you're referring > to the crt objects. > > so when you say "part of the startup code in statically linked programs", it > makes it sound like this file is not used in shared programs which is not the > case at all. > > how about: > /* This file provides __libc_start_main which is responsible for initializing > the glibc runtime before transferring execution to the main function. It is > called from the startup code statically linked into all programs (e.g. the > crt1.o object that provides the _start symbol). > > In a statically linked program, it is linked directly into the image via the > libc.a archive. In a dynamically linked program, it is part of libc.so. */ > -mike By being part of the startup code, I meant code that runs very early, before full platform initialization (like the TCB). In the statically linked base, __libc_start_main is in that category. But in the dynamically linked case, it runs very late (after ELF constructors for the initially loaded DSOs, for example). This is an important distinction, I think. We can argue about this some more, or split the file in two. 8-) Thanks, Florian