From patchwork Tue Jul 26 14:04:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Petazzoni X-Patchwork-Id: 1660814 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=nwpfVn00; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=uclibc-ng.org (client-ip=2a00:1828:2000:679::23; helo=helium.openadk.org; envelope-from=devel-bounces@uclibc-ng.org; receiver=) Received: from helium.openadk.org (helium.openadk.org [IPv6:2a00:1828:2000:679::23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Lsdw16n8Nz9sB4 for ; Wed, 27 Jul 2022 00:05:03 +1000 (AEST) Received: from helium.openadk.org (localhost [IPv6:::1]) by helium.openadk.org (Postfix) with ESMTP id 107C431E0727; Tue, 26 Jul 2022 16:04:54 +0200 (CEST) Authentication-Results: helium.openadk.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=nwpfVn00; dkim-atps=neutral Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) by helium.openadk.org (Postfix) with ESMTPS id E170C31E006C for ; Tue, 26 Jul 2022 16:04:50 +0200 (CEST) Received: (Authenticated sender: thomas.petazzoni@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 88815200008 for ; Tue, 26 Jul 2022 14:04:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1658844290; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=XDFSl3ef8YoPf1hMVmKuef/cpubiYK7tE2H+p1PupBY=; b=nwpfVn00vJ0JuiwSMUoEUbMzWJj5MnMpLc/xHE/BpHy/K1X/kVfqq5DvC1Mi9pgcEjQ3M2 iUscmJwG70bidCWuEuSaoPHRHEfZARTYvAglUm5n3c6cNykyzsFsGPG5Rn6shzZIXxbV2R vr7eVjDb2tNtmCH4s59o6eLe2lKM52yHGSmO073id0IoZMg6wYW8QyJ6BTmYnLAoVv3L9Z n/EeykORHY50w8xBjkwddhtlMnylDgTm361UmMmSa1Z9JwWuRIJUjkQxNL6X746lH719zI Cvpv4pvz5CMmtlxitm+VXaLC/DVptepzGwzmLUR5AVUrBH6pjLkodYuwq41uFQ== Date: Tue, 26 Jul 2022 16:04:49 +0200 From: Thomas Petazzoni To: devel@uclibc-ng.org Message-ID: <20220726160449.66bf6e7d@windsurf> Organization: Bootlin X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Message-ID-Hash: 3EWWXKRMNPGO46HXXGK7GWUSW3ZVNKMA X-Message-ID-Hash: 3EWWXKRMNPGO46HXXGK7GWUSW3ZVNKMA X-MailFrom: thomas.petazzoni@bootlin.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Subject: [uclibc-ng-devel] Odd thing in aarch64 support List-Id: uClibc-ng Development Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hello, While looking at some uClibc code, I stumbled across the following snippet in Rules.mak: UCLIBC_LDSO_NAME := ld-uClibc ARCH_NATIVE_BIT := 32 ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 powerpc64 s390x sparc64 x86_64 kvx ),) UCLIBC_LDSO_NAME := ld64-uClibc ARCH_NATIVE_BIT := 64 else ifeq ($(CONFIG_MIPS_N64_ABI),y) UCLIBC_LDSO_NAME := ld64-uClibc ARCH_NATIVE_BIT := 64 endif endif I was surprised not to see aarch64 in the list of 64-bit architectures here. Turns out that the situation is not that simple in fact. Indeed, gcc does not expect all 64-bit architecture to have their dynamic loader called ld64-uClibc. For aarch64 specifically, it indeed assumes the dynamic loader is called ld-uClibc, which explains why it is working today. However, it means that ARCH_NATIVE_BIT is defined to 32 on aarch64, which is obviously (?) wrong. But turns out that ARCH_NATIVE_BIT is only used in utils/porting.h to define __WORDSIZE and __WORDSIZE is only used in utils/ldd.c. So to me, it seems like this would gain in being clarified. Something like (completely untested): Best regards, Thomas Petazzoni diff --git a/Rules.mak b/Rules.mak index 3fb64c728..a0b012d7f 100644 --- a/Rules.mak +++ b/Rules.mak @@ -142,17 +142,8 @@ export MAJOR_VERSION MINOR_VERSION SUBLEVEL VERSION ABI_VERSION LC_ALL LIBC := libc SHARED_LIBNAME := $(LIBC).so.$(ABI_VERSION) -UCLIBC_LDSO_NAME := ld-uClibc -ARCH_NATIVE_BIT := 32 -ifneq ($(findstring $(TARGET_ARCH) , hppa64 ia64 powerpc64 s390x sparc64 x86_64 kvx ),) -UCLIBC_LDSO_NAME := ld64-uClibc -ARCH_NATIVE_BIT := 64 -else -ifeq ($(CONFIG_MIPS_N64_ABI),y) -UCLIBC_LDSO_NAME := ld64-uClibc -ARCH_NATIVE_BIT := 64 -endif -endif +UCLIBC_LDSO_NAME := $(call qstrip,$(TARGET_LDSO_NAME)) +ARCH_NATIVE_BIT := $(call qstrip,$(TARGET_ARCH_BITS)) UCLIBC_LDSO := $(UCLIBC_LDSO_NAME).so.$(ABI_VERSION) NONSHARED_LIBNAME := uclibc_nonshared.a diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in index a49278b30..e6369bd82 100644 --- a/extra/Configs/Config.in +++ b/extra/Configs/Config.in @@ -145,6 +145,26 @@ config TARGET_xtensa endchoice +config TARGET_LDSO_NAME + string + default "ld64-uClibc" if TARGET_ia64 + default "ld64-uClibc" if TARGET_powerpc64 + default "ld64-uClibc" if TARGET_sparc64 + default "ld64-uClibc" if TARGET_x86_64 + default "ld64-uClibc" if TARGET_kvx + default "ld64-uClibc" if CONFIG_MIPS_N64_ABI + default "ld-uClibc" + +config TARGET_ARCH_BITS + int + default 64 if TARGET_aarch64 + default 64 if TARGET_ia64 + default 64 if TARGET_powerpc64 + default 64 if TARGET_sparc64 + default 64 if TARGET_x86_64 + default 64 if TARGET_kvx + default 64 if CONFIG_MIPS_N64_ABI + default 32 menu "Target Architecture Features and Options"