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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 2F2783858010 for ; Tue, 14 Dec 2021 21:53:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2F2783858010 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-387-6VrMI_HtM1yFueGPA4xRhA-1; Tue, 14 Dec 2021 16:53:22 -0500 X-MC-Unique: 6VrMI_HtM1yFueGPA4xRhA-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 ABE87190A7A1; Tue, 14 Dec 2021 21:53:21 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.17.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9EC951037F5A; Tue, 14 Dec 2021 21:53:20 +0000 (UTC) From: Florian Weimer To: Fangrui Song Cc: Adhemerval Zanella , GNU C Library Subject: Re: [PATCH] elf: Add elf checks for main executable References: <6386c389-086d-e123-d4d6-a97777f207ed@linaro.org> <87czm8quz3.fsf@oldenburg.str.redhat.com> <871r2nmmaf.fsf@oldenburg.str.redhat.com> <20211214001742.lbleuljd2dgmfinx@google.com> <87sfuvsgll.fsf@oldenburg.str.redhat.com> <20211214192411.qfwmv576757n4ciz@google.com> <1ff795dc-d001-ca49-d787-accc6740956b@linaro.org> <20211214213017.26ykobarym4kr7il@google.com> Date: Tue, 14 Dec 2021 22:53:17 +0100 In-Reply-To: <20211214213017.26ykobarym4kr7il@google.com> (Fangrui Song's message of "Tue, 14 Dec 2021 13:30:17 -0800") Message-ID: <87h7baq2eq.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.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_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, 14 Dec 2021 21:53:28 -0000 * Fangrui Song: > Should we consider different target triples as different ABI? > > * Debian/Ubuntu use Debian-style multiarch target triples like x86_64-linux-gnu. > * RedHat uses target triples like x86_64-redhat-linux (considered questionable by some folks: https://reviews.llvm.org/D110900) > * Suse uses target triples like x86_64-suse-linux (considered questionable by some folks). Debian path layout isn't quite compatible with glibc upstream (/etc/ld.so.cache papers over that to some extent), but that's not the issue here. The LLVM review refers to an internal GCC path that can be queried from the gcc command line, so this is mostly a performance issue or distribution integration issue (e.g., llvm/clang package postinst could run gcc to determine the right path). Even if you know the subdirectory under /usr/lib/gcc to use, you still need to guess the appropriate compiler version. So this is really deeply internal stuff. config.guess reports x86_64-pc-linux-gnu on these systems, so there is no material difference. These internal GCC paths are not required at all to match the triplet. > Currently there is no rigid enforcement that one target triple doesn't > run on another, but a mechanism could be developed if you want to > prevent "running one distro's exe on another leads to crash". > This practice can make some software unhappy as they currently release > binary releases which may run a different distro, which even if brittle, > sometimes/oftentimes work. Debian, Red Hat, and SUSE pay fairly close attention to each other and make sure that binaries are more or less portable, as far as the core library version constraints permit (e.g. you can move a Debian 11 binary that uses just glibc and libstdc++ to Red Hat Enterprise Linux 8 and it is expected to work, unless of course it relies on some Debian specifics in its application logic). LSB may be dead, but its spirit lives on in the form of distribution-independent ABIs for the core run-time libraries. A current example is the work on the libgfortran float128 ABI for POWER. This is a bunch of tricky ABI work which could have been avoided by a flag day and essentially a private per-distribution ABI (the ABI would per quasi-distribution-specific for some time because different distributions would switch to float128 at different times). A much smaller example is the recent glibc rseq integration, which has a large part that can be backported without ABI changes, for distributions that are interested in the sched_getcpu acceleration. > As my blog post says, ELFOSABI_NONE will unlikely change EI_ABIVERSION for RELR. > Is the proposal "if ld.bfd --pack-dyn-relocs=relr-glibc is specified, > and the output is otherwise ELFOSABI_NONE or ELFOSABI_GNU, use > ELFOSABI_GNU and bump EI_ABIVERSION to 4"? This ELFOSABI_GNU is not > elegant as RELR is not a GNU extension. OK, I have objection but not so > strongly. > > Since ld.lld --pack-dyn-relocs=relr is there and won't change the > behavior, ld.lld's relr-glibc will likely just be an alias without doing > the EI_ABIVERSION dance. If ld.lld will ignore what the ABI says regarding feature lockout, we have two options: * Ditch the idea of the lockout because it won't work reliably anyway. * In upstream glibc, accept DT_RELR only if the lockout is also present. That is, ld.lld DT_RELR will not work with upstream glibc until it produces the proper markup. The second approach would qualify as the nuclear option, I guess. Thanks, Florian