From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 6266E3858D38 for ; Sat, 24 Sep 2022 18:56:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6266E3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1664045761; bh=2ePen5CR7tnOCsc9dG3tpXJDNUqsPGJXH6iM5ohh2wU=; h=Subject:From:To:Date:In-Reply-To:References:From; b=JYYsEdsyDgj+oJgWtOTTAUaB+h/pINJkZRcYxmhrRpqBDCDxxAFXheT0obvtJZPT8 3MmvSOBp049pfc9vZdoX+6AlSjKTcYYZ7sdOJ4n2lrNcBMGnwSUm9XDQxZcDtgkfsf KITKLt880Xudfp3Fjk7OY6Rh5a8UHVcjTyFXlJa4= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id B26A765AA9; Sat, 24 Sep 2022 14:56:00 -0400 (EDT) Message-ID: Subject: Re: Arm AARCH64 string alignment in .rodata From: Xi Ruoyao To: Bob Plantz , "gcc-help@gcc.gnu.org" Date: Sun, 25 Sep 2022 02:55:58 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_PDS_OTHER_BAD_TLD autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sat, 2022-09-24 at 18:24 +0000, Bob Plantz via Gcc-help wrote: > On 64-bit Raspberry Pi OS, gcc aligns strings in the .rodata section > on 64-bit boundaries: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .text > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .section=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 .rodata > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .align=C2=A0 3 > .LC0: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .string "Enter a number: " > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .align=C2=A0 3 > .LC1: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .string "%i" > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .align=C2=A0 3 > .LC2: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .string "Result: %i\n" > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .text > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .align=C2=A0 2 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .global main > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .type=C2=A0=C2=A0 main, %funct= ion > main: >=20 > I understand the 32-bit boundary for the .text (32-bit instructions), > but the element in a string is a byte. Arm documentation says that > array addresses should be aligned at the element size. Why align the > first character at a 64-bit boundary? Does this have to do with cache > alignment? In gcc/config/aarch64/aarch64.h:110: /* Align definitions of arrays, unions and structures so that initializations and copies can be made more efficient. This is not ABI-changing, so it only affects places where we can see the definition. Increasing the alignment tends to introduce padding, so don't do this when optimizing for size/conserving stack space. */ If you use -Os, ".align 2" won't show up. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University