From owner-freebsd-arm@freebsd.org Thu Jul 11 15:29:43 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C57F415D6633 for ; Thu, 11 Jul 2019 15:29:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8C5E84171 for ; Thu, 11 Jul 2019 15:29:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: U69Qg9wVM1l6Kjzk24IlGHabscckCyDpv.k8RioH_Ln4yBXnfPTsHBtEZ6NbCQR muqFMC3umEvxH24A397wfPo86Dl4KPlaS33C5iAtg0IxBYV1e5TplhQ8plJa7E2UzjYRx0HHZlis IkG27kXkcXfO2tTkVNL1SMiJFcS9Fwl0.x243hnaFXP_Ln6u9DG64_Ij1QHbU3jhoA_uzyWRYKGD DYCLlITHfvzgIaAv0CsxYMDMnQSbDskxh2jNEzimRjHZIWD7y94D2TueTih45hzO96GABPMkOgpr mmKJq1O28YTLow1ggdPVTw1Vp5K1YDkhGo6XpaTp2.kSG0ykuCwxlHqJAps8sY0qQcnCWJc9.zSJ VICSLtdRQo9cB73QBUvjlDtJouXAgIEzZMcY3xkcwNzBeqGbzvBQNSwEfuqdjo5cgoCceHOuNf8k IyBbgKA9c58hws_LusAkYzeUftj0W9NGFdlxWwGjQ9MdI8UiLFeGzkd7ux.tlW5hAcBcN8QQcs0j LfFeREtE751.EH2uUCF_PcuSXzNIWk66W.JYRzrauJH7XPhWSJgrVhIKFVbN0MZd.thVVfWgAoAK dW2wnVJc1vqKd0dxMjBnKSoFU_XcfV0q1oISqWpNOjP.wt2uZaXvw.xJmbbsxz8CiVkIKkCduEPo P698QejHchN21PZoqBw0xKMZPJrhqHhLn9WB8_KBxzHPoYCWv77hSFhMBtrOhFcxTby5wRIhB_fM c3jp3QDppy_4D8D_OqvrkfuhP8xN6Zoztkvmz7uuB3EQPGEpsYFQ20nBTcJjRjVP7_aBbVYekFot 5sevrizJCcJzcm9fqZZj0K_k7E9mmY3eboHIJLlEbGLk328cFVqRvneOfhVw9ltu35TktbK_2evO sPXbOCYRqDbjuKhD1BVq3GQTs4xwgxRfYsdY3Q2clDw_EYjO3Gly0QPBilyud1Qw7WL2422gnRAl ye2vv.EDHEZxWcwv4.YxUf943WpU37Him2KG7wS6K8nc5UPESupE1Oq8i77zgH4Lrgc5TXRtN5p7 BghKjIyiq07QYccM2XMgmXowakqSzd0wqz0UTL60RpsywjvE2wiWISULTIDQMvNrxO0lAL4OE3Ys zt7s9HoUQQ0TRs934EHbshow1RX7ecz9yG93Dy77.KYJaoobiIo6817vcdQMy5eZ3XFdmUpgdWcn ay.dchn9FL3Uwf_1ZlEb17J6Lo2qkEYpln4k098RGmhI95V7Slpoyx6QwWWJ9HHShm.CNvME1YVc M2gXIlkx5xfLLbZMcgV1Sf1welNjfU36ynR9LZjhMfb9agh7QHZiH4T8GoEEc8IFzj6Z_VcNwcYs - Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 11 Jul 2019 15:29:40 +0000 Received: by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 05cd4b3498b908307eabf69e371145f4; Thu, 11 Jul 2019 15:29:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: FreeBSD arm EABI5 documentation? From: Mark Millard In-Reply-To: Date: Thu, 11 Jul 2019 08:29:35 -0700 Cc: Robert Crowston via freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <1CB61FE0-5665-424F-8B94-ABFC06906112@yahoo.com> References: <1788e13e706b9fdaf610e4ddd671a5ed715f9dfe.camel@freebsd.org> To: adr X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: B8C5E84171 X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.12 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.26)[0.259,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.94)[0.945,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.990,0]; RCVD_IN_DNSWL_NONE(0.00)[123.129.6.74.list.dnswl.org : 127.0.5.0]; IP_SCORE(1.43)[ip: (4.66), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.14), country: US(-0.06)]; RWL_MAILSPIKE_POSSIBLE(0.00)[123.129.6.74.rep.mailspike.net : 127.0.0.17] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 15:29:43 -0000 On 2019-Jul-10, at 15:18, Mark Millard wrote: >=20 > On 2019-Jul-10, at 13:47, adr wrote: >=20 >> On Wed, 10 Jul 2019, Ian Lepore wrote: >>=20 >>> That's... odd. The arm spec requires the stack to be 8-byte aligned = at >>> any public interface. It's hard to imagine how anything could work >>> properly if it were not, given that the toolchains will assume that = 64- >>> bit values are aligned at 64-bit boundaries and will thus generate >>> instructions that require that alignment (require it even if strict >>> alignment checking for most instructions is disabled in the control >>> register). If you could enter a function with the stack only 4-byte >>> aligned, how would the compiler know it's safe to use something like = an >>> LDREXD instruction on a local variable allocated on the stack? >>=20 >> I have no idea. The only thing I can assure you is that in the code = I'm >> talking about (a forth implementation using SDL2) I've never aligned = the >> C stack when passing arguments to external functions. Until now! >=20 > Curious, I looked around in NetBSD code and found the likes of: >=20 > /* ARM-specific macro to align a stack pointer (downwards). */ > #define STACK_ALIGNBYTES (8 - 1) >=20 > in netbsd's src/sys/arch/arm/include/param.h . >=20 > In src/sys/arch/aarch64/include/param.h there is: >=20 > /* AARCH64-specific macro to align a stack pointer (downwards). */ > #define STACK_ALIGNBYTES (16 - 1) >=20 >=20 > So it appears that the kernel does have stack alignment: > src/sys/sys/param.h has . . . >=20 > #if defined(_KERNEL) || defined(__EXPOSE_STACK) > . . . > #ifndef STACK_ALIGNBYTES > #define STACK_ALIGNBYTES __ALIGNBYTES > #endif > . . . > #define STACK_ALIGN(sp, bytes) \ > ((char *)(((unsigned long)(sp)) & ~(bytes))) > . . . > #define STACK_LEN_ALIGN(len, bytes) (((len) + (bytes)) & = ~(bytes)) >=20 > There is code for signal delivery: >=20 > void > sendsig_siginfo(const ksiginfo_t *ksi, const sigset_t *mask) > { > . . .=09 > fp =3D getframe(l, sig, &onstack); > =09 > /* make room on the stack */ > fp--; > =09 > /* make the stack aligned */ > fp =3D (struct sigframe_siginfo *)STACK_ALIGN(fp, = STACK_ALIGNBYTES); > . . . >=20 > AARCH64 even has for runing 32-bit code: >=20 > static void > netbsd32_sendsig_siginfo(const ksiginfo_t *ksi, const sigset_t *mask) > { > . . . > fp =3D (struct netbsd32_sigframe_siginfo *)sp; > fp =3D (struct netbsd32_sigframe_siginfo *)STACK_ALIGN(fp - 1, = 8); > . . . >=20 > (But that last looks wrong: 8 should likely be 8-1, as in > STACK_ALIGNBYTES for 32-bit ARM.) >=20 > There is: >=20 > static size_t > calcstack(struct execve_data * restrict data, const size_t gaplen) > { > . . . > /* make the stack "safely" aligned */ > return STACK_LEN_ALIGN(stacklen, STACK_ALIGNBYTES); > } >=20 > I saw other comments mentioning ' stack "safely" aligned' when > looking around. >=20 > So it basically matches up with Ian's comments at the kernel vs. user > space interface, despite the probable netbsd32_sendsig_siginfo error. I had an exchange via Jared McNeill (who is active on NetBSD) that involved NetBSD's criteria. Overallit went like this for that aspect of the exchange: QUOTE From: Nick Hudson Subject: Re: netbsd32_sendsig_siginfo STACK_ALIGN use problem? Date: July 11, 2019 at 03:59:52 PDT To: Jared McNeill , Mark Millard On 11/07/2019 11:21, Jared McNeill wrote: > Hi Mark =E2=80=94 >=20 > This isn=E2=80=99t really an area I am familiar with. Nick Hudson (in = copy), our resident arm expert, can likely help. >=20 > Cheers, > Jared >=20 >=20 >> On Jul 10, 2019, at 7:17 PM, Mark Millard = wrote: >>=20 >> Curious about 32-bit arm stack alignment requirements in netbsd >> (based on a FreeBSD thread making claims that user space allows >> 4-byte stack alignment), I went looking around some in NetBSD >> code. . . . >>=20 8 byte stack alignment is a requirement of = http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.p= df 5.2.1.2 Stack constraints at a public interface The stack must also conform to the following constraint at a public = interface: SP mod 8 =3D 0. The stack must be double-word aligned I hope this helps. END QUOTE (I was really reporting a coding error in netbsd32_sendsig_siginfo relative to meeting this criteria.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)