From nobody Wed Nov 15 18:23:27 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SVs4D46Xrz50b2c for ; Wed, 15 Nov 2023 18:23:40 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SVs4D02JRz4QBX for ; Wed, 15 Nov 2023 18:23:40 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4083740f92dso57108435e9.3 for ; Wed, 15 Nov 2023 10:23:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700072618; x=1700677418; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YfSwpvwtjomOymK8q9uYfNiMrsbUXQ9Fhv2qryi/32s=; b=Lebm2FWgEEES4R7gb4ESCKe/76V6bRPbvTl3Le378rBVYUwzvI/aGuqpYlCKPbtG3n TcTIIV05OL+6NhAfsdlniFR81nrrDBqibq8n7LHXBBEcsX1d9ceow80Hg3FopINr7DgJ zfnKiJh/pceXUoAtdZL6SHAjsgmuT8ZgTrXM3aH9onhVyB+56cdH5BlQPfphywy9e8j/ BSxqf2vXXUgNgRevLrV4FOfasPh0TdOkK7Y5FzwB/wLwanRFoaTZz1SD7JbGTXv7zolw rpYmrIMQMJUS2QezrR5JR7lsvs+l9kR4uU6uk/jGmUbty3qCouLgDI/OXuQEIPH4zQL1 5eAA== X-Gm-Message-State: AOJu0YwEO6oQ2PJb+uyESu2gl9Idn4leBTflcY1MxBP8XdE8plb4JF80 iNFV/DPXYFpBxdGI4070wOKMMaeeKyXNc64jblUlRA== X-Google-Smtp-Source: AGHT+IHf30SZh3haGJcCN6H9EKIU8Ej6th4TwpTPw0H+6D3Dl6KLeK8vuzZnGNRlBUtsTyMBqOMxzw== X-Received: by 2002:a05:600c:3b8d:b0:408:3c8a:65ec with SMTP id n13-20020a05600c3b8d00b004083c8a65ecmr10884599wms.8.1700072618144; Wed, 15 Nov 2023 10:23:38 -0800 (PST) Received: from smtpclient.apple ([131.111.5.246]) by smtp.gmail.com with ESMTPSA id je14-20020a05600c1f8e00b00405bbfd5d16sm524779wmb.7.2023.11.15.10.23.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2023 10:23:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: git: 7eb26be9c808 - main - arm64: Use adrp + :lo12: to load globals from asm From: Jessica Clarke In-Reply-To: <202311151812.3AFICH9p077368@gitrepo.freebsd.org> Date: Wed, 15 Nov 2023 18:23:27 +0000 Cc: "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <202311151812.3AFICH9p077368@gitrepo.freebsd.org> To: Andrew Turner X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4SVs4D02JRz4QBX On 15 Nov 2023, at 18:12, Andrew Turner wrote: >=20 > The branch main has been updated by andrew: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D7eb26be9c8080686f64fdc0a28e5ae78= 39bbc82d >=20 > commit 7eb26be9c8080686f64fdc0a28e5ae7839bbc82d > Author: Andrew Turner > AuthorDate: 2023-11-11 09:27:30 +0000 > Commit: Andrew Turner > CommitDate: 2023-11-15 18:05:08 +0000 >=20 > arm64: Use adrp + :lo12: to load globals from asm >=20 > When loading a global variable we can use a pseudo-instruction = similar > to "ldr, xn, =3Dglobal" to load the address of the symbol. As this = is > unlikely to be supported by a mov instruction a pc-relative load is > used, with the absolute address written at the end of the function = so > it will be loaded. >=20 > This load can be partially replaced with an adrp instruction. This > generates the address, aligned to a 4k boundary, using a = pc-relative > addition. Because the address is 4k-aligned we then update reading = the > global variable using a load with the offset of the load the low > 12-bits of the global. Arm64 assemblers have :lo12: to support = this, > e.g. "ldr xn, [xn, :lo12:global]". >=20 > The only remaining users of "ldr, xn, =3Dglobal" that I can find = are > executed from the physical address space the kernel was loaded in = and > need an address in the kernels virtual address space. Because of = this > they can't use adrp. >=20 > Sponsored by: Arm Ltd > Differential Revision: https://reviews.freebsd.org/D42565 I assume the motivation for this, which seems to be missing from the description, is that it removes an unnecessary level of indirection, rather than that there are issues with the PC-relative load literal instruction not working, given that I doubt we=E2=80=99re hitting the 1 = MiB literal pool offset range limit in hand-written assembly? Jess