Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Danny Milosavljevic writes: Hi Danny, Grishka! > On Fri, 08 Jan 2021 08:16:29 +0100 > grischka wrote: > >> But no such thing happens in this case. The 'ptr' in init_putv() >> comes from >> >> ptr = sec->data + c; >> >> and it seems that if tcc is doing the right thing then 'c' cannot >> be misaligned, and if malloc/realloc on that system is doing the >> right thing, then sec->data cannot be misaligned either. So...? > > How does tcc allocate dynamic memory? I've tried to find out, but > tcc_malloc is defined to be "use_tcc_malloc", which I don't find > anywhere. Does it use libc malloc for that ? > > (With MEM_DEBUG defined, tcc_malloc_debug seems to use malloc. But > what about without MEM_DEBUG defined ?) > > If so, is libc malloc supposed to ensure alignment of allocated memory? > > According to https://man7.org/linux/man-pages/man3/malloc.3.html yes. > > @Janneke: So our mes libc malloc should be aligning the stuff--but it's not > doing it. So it's a bug in our libc. Beautiful! Maybe this explains other differences we saw between aarch64-linux and arm-linux? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Hi grischka, Hi Janneke, On Fri, 08 Jan 2021 08:16:29 +0100 grischka wrote: > But no such thing happens in this case. The 'ptr' in init_putv() > comes from > > ptr = sec->data + c; > > and it seems that if tcc is doing the right thing then 'c' cannot > be misaligned, and if malloc/realloc on that system is doing the > right thing, then sec->data cannot be misaligned either. So...? How does tcc allocate dynamic memory? I've tried to find out, but tcc_malloc is defined to be "use_tcc_malloc", which I don't find anywhere. Does it use libc malloc for that ? (With MEM_DEBUG defined, tcc_malloc_debug seems to use malloc. But what about without MEM_DEBUG defined ?) If so, is libc malloc supposed to ensure alignment of allocated memory? According to https://man7.org/linux/man-pages/man3/malloc.3.html yes. @Janneke: So our mes libc malloc should be aligning the stuff--but it's not doing it. So it's a bug in our libc. pgpchjZrn1jel.pgp Description: OpenPGP digital signature
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
> Jan Nieuwenhuizen wrote: Hello Arnold! >> to the gawk-mesbot0 recipe also fixes "inc.awk". The pre >> increment/decrement code looks like this: >> >> --8<---cut here---start->8--- >> *lhs = make_number(lval + >> (tree->type == Node_preincrement ? 1.0 : -1.0)); >> >> --8<---cut here---end--->8--- > > What in the world? That looks like gawk 3.x code, which is > terribly ancient. What project is still using a version that old? We are removing binary seeds from the GNU Guix package graph. The binary packages in Guix form an acyclic graph and at the bottom of the graph we originally had binutils, glibc, gcc, bash, coreutils&co (gawk, gzip, sed, tar, ...). Since 2016 we have been working to eliminate those binary seeds. For a complete overview and more background see https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ but what we did is remove all those, replacing them by Stage0, GNU Mes, tinycc...and multiple versions of ancient GNU tools. Using ancient tools is less than great, we are using those because "it works" or rather, we didn't succeed as yet using newer versions. Often, newer versions of a software are more demanding in their requirements and are less bootstrappale. In other cases, ancient software does not build with newer tools, because they are more strict. > Arnold > (The gawk maintainer) Thanks for reaching out! Sadly I do not have more concrete information (let alone a bug report or feature request) for you yet, other than that we are using gawk-3.0.0, lateron v3.1.8, and only finally v5.0.1. Simalarly for other tools. The biggest hudle was bootstrapping glibc and gcc, as you can imagine. Currently, we start with gcc-2.95.3 and I would very much like to target gcc-4.6.4 directly instead. For a tool as gawk, it would be great to be able to the latest greatest! Greetings, Janneke (GNU Mes author) -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Jan Nieuwenhuizen wrote: > to the gawk-mesbot0 recipe also fixes "inc.awk". The pre > increment/decrement code looks like this: > > --8<---cut here---start->8--- > *lhs = make_number(lval + > (tree->type == Node_preincrement ? 1.0 : -1.0)); > > --8<---cut here---end--->8--- What in the world? That looks like gawk 3.x code, which is terribly ancient. What project is still using a version that old? Arnold (The gawk maintainer)
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Danny Milosavljevic wrote:
int main() {
double f = 1.0;
return 0;
}
...
I get a bus error here:
│ 0x24698 vstr d0, [r0]
│
...
And indeed, (0x24b01e % 8) == 6, not 0.
...
*(double *)ptr = vtop->c.d
(the latter of which emits VFP instructions that expect double-aligned
pointers).
It seems that in fact, on certain systems, initializing intentionally
misaligned (packed) structure members could crash tcc already during
compilation.
But no such thing happens in this case. The 'ptr' in init_putv()
comes from
ptr = sec->data + c;
and it seems that if tcc is doing the right thing then 'c' cannot
be misaligned, and if malloc/realloc on that system is doing the
right thing, then sec->data cannot be misaligned either. So...?
--- grischka
