From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id mD6dORb7919bBwAA0tVLHw (envelope-from ) for ; Fri, 08 Jan 2021 06:26:30 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id MC3INBb791+AGgAAbx9fmQ (envelope-from ) for ; Fri, 08 Jan 2021 06:26:30 +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 14DD594043B for ; Fri, 8 Jan 2021 06:26:30 +0000 (UTC) Received: from localhost ([::1]:41124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxlEC-0003Yt-Rf for larch@yhetil.org; Fri, 08 Jan 2021 01:26:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxlDp-0003Xq-FL; Fri, 08 Jan 2021 01:26:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48851) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxlDm-0001TV-Lh; Fri, 08 Jan 2021 01:26:02 -0500 Received: from [2001:980:1b4f:1:42d2:832d:bb59:862] (port=53638 helo=dundal.janneke.lilypond.org) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kxlDj-0003pE-W4; Fri, 08 Jan 2021 01:26:01 -0500 From: Jan Nieuwenhuizen To: Danny Milosavljevic Subject: Re: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello' Organization: AvatarAcademy.nl References: <87im8cvdpa.fsf@gnu.org> <36b3777d90af6fa2e1c1778ba183111e@codethink.co.uk> <87lfd5rpr8.fsf@gnu.org> <20210107211058.40e0813a@scratchpost.org> <20210107212324.36bfd236@scratchpost.org> <20210107235208.04835b95@scratchpost.org> X-Url: http://AvatarAcademy.nl Date: Fri, 08 Jan 2021 07:25:52 +0100 In-Reply-To: <20210107235208.04835b95@scratchpost.org> (Danny Milosavljevic's message of "Thu, 7 Jan 2021 23:52:41 +0100") Message-ID: <87ble0ueq7.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.85 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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: 14DD594043B X-Spam-Score: -2.85 X-Migadu-Scanner: scn0.migadu.com X-TUID: S46GdUjVTVxQ Danny Milosavljevic writes: Hello Danny, > I just found the bug in tinycc that caused failed our ARM bootstrap to fa= il. > > I use the following reproducer: > > int main() { > double f =3D 1.0; > return 0; > } Beautiful! Well done! I can confirm that adding this patch --8<---------------cut here---------------start------------->8--- diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm index a50a238ddd..5a3fa694b3 100644 --- a/gnu/packages/commencement.scm +++ b/gnu/packages/commencement.scm @@ -1417,8 +1417,8 @@ ac_cv_c_float_format=3D'IEEE (little-endian)' (substitute* "test/Makefile.in" (("^bigtest:.*") "bigtest: basic\n") (("( |\t)(childin|convfmt|fflush|longwrds|math|negexp)" a= ll sep) sep)) - (substitute* "io.c" - (("char rs;") "int rs;")) + (substitute* '("builtin.c" "eval.c" "io.c") + (("1.0") "1")) #t)) (add-before 'configure 'setenv (lambda _ --8<---------------cut here---------------end--------------->8--- to the gawk-mesbot0 recipe also fixes "inc.awk". The pre increment/decrement code looks like this: --8<---------------cut here---------------start------------->8--- *lhs =3D make_number(lval + (tree->type =3D=3D Node_preincrement ? 1.0 : -1.0)); --8<---------------cut here---------------end--------------->8--- > on ARM (32) using your patched tcc. (but it's also broken in the unpatch= ed 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 Ah, so it may result in a wrong assingment, or bus error even. Great! > Debugging some more, I find: > > tccgen.c: > > /* store a value or an expression directly in global data or in local arr= ay */ > 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= the > same representation on host and target, which is likel= y 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] Ah yes, this code has been problematic in the sense that I found bus errors here and tried workarounds several times (look at the wip-arm-bootstrap14 branch). > 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. Ah...I wasn't aware of this requirement... > Alignment could be disabled on the CPU > > https://developer.arm.com/documentation/ddi0464/f/system-control/regist= er-descriptions/system-control-register > > but I don't think EABI wants that. Hmm, what does this mean? We are not really using EABI, or are we? We seem to need this terrible hack --8<---------------cut here---------------start------------->8--- diff --git a/tccelf.c b/tccelf.c index 2ac7466c..42546f57 100644 --- a/tccelf.c +++ b/tccelf.c @@ -1867,7 +1867,7 @@ static void tcc_output_elf(TCCState *s1, FILE *f, int= phnum, ElfW(Phdr) *phdr, ehdr.e_ident[EI_OSABI] =3D ELFOSABI_FREEBSD; #endif #ifdef TCC_TARGET_ARM -#ifdef TCC_ARM_EABI +#if defined (TCC_ARM_EABI) || BOOTSTRAP ehdr.e_ident[EI_OSABI] =3D 0; ehdr.e_flags =3D EF_ARM_EABI_VER4; if (file_type =3D=3D TCC_OUTPUT_EXE || file_type =3D=3D TCC_OUTPUT_DLL) --8<---------------cut here---------------end--------------->8--- at least to get tcc's ARM binaries to run on Aarch64-Linux. Is this related; iow, could it be that this "fix" for Aarch64 break ARM? > 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. OK. > 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 likel= y to >> be wrong in the case of long double */ > > Yeah, and even when NOT cross-compiling, the alignment is wrong--which me= ans > 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 elemen= ts > 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). So alignment should be fixed, but that's more work and you propose a workaround, right? I'm struggling to understand the implications of this last bit...guessing you will be preparing a patch for the mes-0.23 branch of our "bootstrappable tinycc"? Oh, and we need that same patch for plain tcc-0.9.27, for "tcc-boot" of course! Greetings, Janneke --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com