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 ESMTPS id CF6B93858D39 for ; Tue, 26 Oct 2021 15:26:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF6B93858D39 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-477-o-KsDJxaNHSWR45PhxbItA-1; Tue, 26 Oct 2021 11:26:00 -0400 X-MC-Unique: o-KsDJxaNHSWR45PhxbItA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0CDF88066F3; Tue, 26 Oct 2021 15:25:59 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.250]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AA15569203; Tue, 26 Oct 2021 15:25:57 +0000 (UTC) From: Florian Weimer To: "H.J. Lu via Libc-alpha" Cc: binutils@sourceware.org, "H.J. Lu" Subject: Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED References: Date: Tue, 26 Oct 2021 17:25:55 +0200 In-Reply-To: (H. J. Lu via Libc-alpha's message of "Tue, 26 Oct 2021 07:53:09 -0700") Message-ID: <87zgqvq03g.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.3 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_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Tue, 26 Oct 2021 15:26:07 -0000 * H. J. Lu via Libc-alpha: > [hjl@gnu-cfl-2 elfvers-1]$ make x > gcc -B./ -o x x.o glibc-2-minor-1.o > [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x > Version symbols section '.gnu.version' contains 4 entries: > Addr: 0x00000000004004ae Offset: 0x0004ae Link: 6 (.dynsym) > 000: 0 (*local*) 2 (GLIBC_2.34) 3 (GLIBC_2.2.5) 1 (*global*) > > Version needs section '.gnu.version_r' contains 1 entry: > Addr: 0x00000000004004b8 Offset: 0x0004b8 Link: 7 (.dynstr) > 000000: Version: 1 File: libc.so.6 Cnt: 4 > 0x0010: Name: GLIBC_2.38 Flags: none Version: 5 > 0x0020: Name: GLIBC_2.35 Flags: none Version: 4 > 0x0030: Name: GLIBC_2.2.5 Flags: none Version: 3 > 0x0040: Name: GLIBC_2.34 Flags: none Version: 2 > > Displaying notes found in: .note.gnu.property > Owner Data size Description > GNU 0x00000040 NT_GNU_PROPERTY_TYPE_0 > Properties: 1_glibc_2_needed: 2.35, 2.38 > ... > [hjl@gnu-cfl-2 elfvers-1]$ ./x > ./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x) > ./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x) > [hjl@gnu-cfl-2 elfvers-1]$ What's the intended use case? This proposal may conflict in spirit with the glibc proposal to support preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 to a glibc 2.28 installation, for example). So far, symbol versions have only been used as a quick check for ABI coverage that also works with lazy binding. This doesn't look the right mechanism to me without also bringing in new marker symbols, in which case the note is not needed. The problem that linkers and loaders ignore unknown types should be tackled in a different way, e.g. by flagging critical types in some way. See: Critical program headers and dynamic tags Thanks, Florian