From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id iAwPFtuV9183TAAA0tVLHw (envelope-from ) for ; Thu, 07 Jan 2021 23:14:35 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id mPvcEduV91/RGQAA1q6Kng (envelope-from ) for ; Thu, 07 Jan 2021 23:14:35 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 12998940274 for ; Thu, 7 Jan 2021 23:14:34 +0000 (UTC) Received: from localhost ([::1]:39290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxeUD-0001cc-Tm for larch@yhetil.org; Thu, 07 Jan 2021 18:14:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51968) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxe9H-0008H7-Dw for guix-devel@gnu.org; Thu, 07 Jan 2021 17:52:55 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:40736) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxe9B-0006IN-7g; Thu, 07 Jan 2021 17:52:55 -0500 Received: from localhost (80-110-127-104.cgn.dynamic.surfer.at [80.110.127.104]) by dd26836.kasserver.com (Postfix) with ESMTPSA id C36673366AA3; Thu, 7 Jan 2021 23:52:44 +0100 (CET) Date: Thu, 7 Jan 2021 23:52:41 +0100 From: Danny Milosavljevic To: Jan Nieuwenhuizen Subject: Re: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello' Message-ID: <20210107235208.04835b95@scratchpost.org> In-Reply-To: <20210107212324.36bfd236@scratchpost.org> References: <87im8cvdpa.fsf@gnu.org> <36b3777d90af6fa2e1c1778ba183111e@codethink.co.uk> <87lfd5rpr8.fsf@gnu.org> <20210107211058.40e0813a@scratchpost.org> <20210107212324.36bfd236@scratchpost.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/aijbPBTUlYUBr.gPIAkpuWz"; protocol="application/pgp-signature"; micalg=pgp-sha512 Received-SPF: none client-ip=85.13.145.193; envelope-from=dannym@scratchpost.org; helo=dd26836.kasserver.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, tinycc-devel@nongnu.org, Michael Matz , Paul Sherwood , bootstrappable@freelists.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.45 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 12998940274 X-Spam-Score: -2.45 X-Migadu-Scanner: scn0.migadu.com X-TUID: LUh8XE1EKgXP --Sig_/aijbPBTUlYUBr.gPIAkpuWz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Janneke, I just found the bug in tinycc that caused failed our ARM bootstrap to fail. I use the following reproducer: int main() { double f =3D 1.0; return 0; } and then invoke tcc a.c on ARM (32) using your patched tcc. (but it's also broken in the unpatched= tcc) (tcc cross compiler is not enough. tcc has to actually itself be an ARM EABI executable) I get a bus error here: =E2=94=82 0x24698 vstr d0, [r0] = = =E2=94=82 Debugging some more, I find: tccgen.c: /* store a value or an expression directly in global data or in local array= */ static void init_putv(CType *type, Section *sec, unsigned long c) { [...] size =3D type_size(type, &align); section_reserve(sec, c + size); // c =3D=3D 0, size =3D=3D 8 ptr =3D sec->data + c; // sec->data =3D=3D 0x24b01e, c =3D=3D 0 switch(bt) { /* XXX: when cross-compiling we assume that each type has t= he same representation on host and target, which is likely = to be wrong in the case of long double */ case VT_BOOL: vtop->c.i =3D vtop->c.i !=3D 0; case VT_BYTE: *(char *)ptr =3D vtop->c.i; break; case VT_SHORT: *(short *)ptr =3D vtop->c.i; break; case VT_FLOAT: *(float*)ptr =3D vtop->c.f; break; case VT_DOUBLE: *(double *)ptr =3D vtop->c.d; break; [... and so on] tccelf.c: /* reserve at least 'size' bytes from section start */ ST_FUNC void section_reserve(Section *sec, unsigned long size) { if (size > sec->data_allocated) // both 8 section_realloc(sec, size); if (size > sec->data_offset) // both 8 sec->data_offset =3D size; } Nothing here make sure that the VFP double is aligned to 8 Byte. And indeed, (0x24b01e % 8) =3D=3D 6, not 0. Alignment could be disabled on the CPU https://developer.arm.com/documentation/ddi0464/f/system-control/register= -descriptions/system-control-register but I don't think EABI wants that. tinycc does have: /* reserve at least 'size' bytes aligned per 'align' in section 'sec' from current offset, and return the aligned offset */ ST_FUNC size_t section_add(Section *sec, addr_t size, int align) { size_t offset, offset1; offset =3D (sec->data_offset + align - 1) & -align; offset1 =3D offset + size; if (sec->sh_type !=3D SHT_NOBITS && offset1 > sec->data_allocated) section_realloc(sec, offset1); sec->data_offset =3D offset1; if (align > sec->sh_addralign) sec->sh_addralign =3D align; return offset; } But that's not used for init_putv. And section_reserve, which is used, doesn't care about alignment at all. (it seems there's a reserved part and a data part in each section, and it holds that the data part elements are aligned--but the reserved part elements are NOT aligned. I don't see how sec->data would be aligned by the dynamic memory allocator either) Other notes: tccgen.c even has this: > /* XXX: when cross-compiling we assume that each type has = the > same representation on host and target, which is likely= to > be wrong in the case of long double */ Yeah, and even when NOT cross-compiling, the alignment is wrong--which means it sometimes won't work at all on ARM, depending on luck. As a workaround, we can patch tcc to instead do the assignments on elements on the stack and then copy those over, instead of doing *(double *)ptr =3D vtop->c.d (the latter of which emits VFP instructions that expect double-aligned pointers). --Sig_/aijbPBTUlYUBr.gPIAkpuWz Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/3kLkACgkQ5xo1VCww uqVJYAf8CDD3zpnt90dbNX5AWWa4HYvYNkQVT+xROA91+dH2UBvInSjDx4s2oXoo lALAWMextMil3I3iFDnJsW4x+L4PFL7WN0N4M0JnxVBONOKQY+fd3hcvCsRgf3nD Rh3wkHMq+9I5dqhUusdXaKOubXLaB2fZhYWUJ9j0dg0xmCO7Gj98aJo7wNHsX/UX ySOeRcBgi3eE5DGCUPYdiMRtBRPEVcupubbLDCOu2hUVktKoK1ijJG0n601CXv7W IM6tjQFLNEGztSjtmECPmSg+BSnqILKSBTE9E+7AyTgzJhOJhT1TtmFyLMR2o10a EPd9qft+THSOi65eKBXEPY78Xk6BCQ== =UOHe -----END PGP SIGNATURE----- --Sig_/aijbPBTUlYUBr.gPIAkpuWz--