From owner-freebsd-arm@freebsd.org Wed Jul 10 22:19:06 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 9E10515E4B70 for ; Wed, 10 Jul 2019 22:19:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 A517974C10 for ; Wed, 10 Jul 2019 22:19:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ghwWXrUVM1mnUWjmI2bF1PwwR97XqdbUQBLs6Yzlv4x_rcSB6T7I.klg2oaBwcS u1susNxnRGePfugUy3UmqKASVKCn6_jmV.wLAvhc_O1BKPsGpY92XIiuzPh65cHxDVGIVIdsWfjS RY16mF8h7jJ0gP8ArLfzdjJBl.PYkAozg7E8da9wPgYyWgKq0_pMWzeNpm5A8aU8v_6yApEo0Liu q2e_rzdsBFIlxrfINieLOusKht3G3f3T1diXm4558sTvK5bJvBYPqJR4SivRrO_29TwChgdUJ2V3 vWr5Bfbw7PO9j.Ip.i5GW9vNkdQardKrVR3lQo.txu3EA3iqWHJlF41PYjL6DXEurGrlU4SdM8ZB tojSkk1HCXAB0irOJ13fcAgz_iginbRUfGZ65UmXKQDAPZhyQ.mYGGk.At6eiSNWhCQYPf8OSWfy jofnEr8InjAuMgJcHaOoPftbFWKho67g1NaR1bPkPk5cyjribRAK2RLlCfWBWv0cB95pAXBhbaqm DNbaRAZNd3HEYRmo8QGOAVs_MmGdLyzDj.WCF.D0o_pTugvmTgDYZr4J2zYts639r.sWNps.0Rx. VypBAm8xfd5utjBpS90flDoJUJydCRdRgeLipFiGB8cEXiKFHU0p_yLyFqpYwNOKU0ctKe1K8T1R nBMHdflEIF7bALDmP6U_s8rc7pilNrexDL1wYUlq5eO40o.kuV1Omwiy_szh9GQsq5lRx0SiSKcF Fmg7f3qHE05M9q1UggbeYNaDZZulzPPogRqyxZ83Vf5uWdU2WN0p6XJl7CswivPkxxNKB729zCko M6iRflglg6V8918jsqhmlFACYNbPd49Hni_T2CvvJ71yen8ollU96UoHEHiPzn1XBO.j6WRhmbDh jXjwi_Nu3x8IeegrnB.FssO.ID5MWHKiLifgZ9vZFVoxwruTuG1WqFSeuOzsheZd4gdcnLgGiu6S QeWhck2cmYu.l5QBqfKPA0XUG82xdEd0pUX1gBt8L57KClWqQVMZkidfuwFXHnpzAB_WIhG3X0CV I2x5Cf05pp0SZ.ra3s93WnKaYnArx91XmQbaXovPu9o13LNPL.URmH5FxqYDn5lN264BGnR9to4u gtmeFmZFTFk_yFlDjYgOF7TwwuVeJMaXArCjn0hcsICrrY55aiS6ov5DvV_Jq.7aT.hPbHfENEh8 JTlBm2pX6IVtBEQMyOIc4p23lH.9F4kAs0kiemTU483mHNcHlUAo.YSttFpglUwTbxFoAzpg_HKI - Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Wed, 10 Jul 2019 22:18:59 +0000 Received: by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f7630e820c96c7593dd0e5e4d048edb8; Wed, 10 Jul 2019 22:18:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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: Wed, 10 Jul 2019 15:18:52 -0700 Cc: Robert Crowston via freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: <1788e13e706b9fdaf610e4ddd671a5ed715f9dfe.camel@freebsd.org> To: adr X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: A517974C10 X-Spamd-Bar: ++++ X-Spamd-Result: default: False [4.57 / 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)[]; IP_SCORE(1.43)[ip: (4.62), ipnet: 74.6.128.0/21(1.43), asn: 26101(1.14), country: US(-0.06)]; 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.73)[0.730,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_SPAM_MEDIUM(0.95)[0.948,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.98)[0.976,0]; RCVD_IN_DNSWL_NONE(0.00)[33.128.6.74.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[] 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: Wed, 10 Jul 2019 22:19:06 -0000 On 2019-Jul-10, at 13:47, adr wrote: > On Wed, 10 Jul 2019, Ian Lepore wrote: > >> 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? > > 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! Curious, I looked around in NetBSD code and found the likes of: /* ARM-specific macro to align a stack pointer (downwards). */ #define STACK_ALIGNBYTES (8 - 1) in netbsd's src/sys/arch/arm/include/param.h . In src/sys/arch/aarch64/include/param.h there is: /* AARCH64-specific macro to align a stack pointer (downwards). */ #define STACK_ALIGNBYTES (16 - 1) So it appears that the kernel does have stack alignment: src/sys/sys/param.h has . . . #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)) There is code for signal delivery: void sendsig_siginfo(const ksiginfo_t *ksi, const sigset_t *mask) { . . . fp = getframe(l, sig, &onstack); /* make room on the stack */ fp--; /* make the stack aligned */ fp = (struct sigframe_siginfo *)STACK_ALIGN(fp, STACK_ALIGNBYTES); . . . AARCH64 even has for runing 32-bit code: static void netbsd32_sendsig_siginfo(const ksiginfo_t *ksi, const sigset_t *mask) { . . . fp = (struct netbsd32_sigframe_siginfo *)sp; fp = (struct netbsd32_sigframe_siginfo *)STACK_ALIGN(fp - 1, 8); . . . (But that last looks wrong: 8 should likely be 8-1, as in STACK_ALIGNBYTES for 32-bit ARM.) There is: 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); } I saw other comments mentioning ' stack "safely" aligned' when looking around. So it basically matches up with Ian's comments at the kernel vs. user space interface, despite the probable netbsd32_sendsig_siginfo error. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)