From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Mon Mar 9 11:25:04 EDT 2020 Received: from stockyard.bk.recurse-network.net (gateway.bk.recurse-network.net [185.230.222.2]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 13113d85 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Mon, 9 Mar 2020 08:24:56 -0700 (PDT) Message-ID: <8B4A701F2DC7A3709CEE84EC68CC50DC@eigenstate.org> To: plan9fullfrontal@qs.co.nz, 9front@9front.org Subject: Re: [9front] APE stddef.h ptrdiff_t should it be 8? [Tcl memory problem] Date: Mon, 9 Mar 2020 08:24:54 -0700 From: ori@eigenstate.org In-Reply-To: <9fc99a18-95f6-a43c-7933-808c3e9d92bc@qs.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: reduce/map-aware CSS database > On 03/09/2020 05:06 PM, ori@eigenstate.org wrote: >> >> I'd really like to know what went wrong with tcl, and how >> to reproduce it. >> > Ok, but you need to understand the tcl code to follow along. I tried to get the tcl code from ports, but it seems like the port for it is a bit broken. Specifically, there's a bug in the mkfile pointing at 'unix/tclAppInit.c;, which should probably be just 'tclAppInit.c'. When I patch that, I get this error: /sys/ports/dev-lang/tcl/work/./tommath.h:94[stdin:28460] external redeclaration of: mp_digit TYPEDEF ULONG /sys/ports/dev-lang/tcl/work/./tommath.h:94[stdin:28460] TYPEDEF UINT /sys/ports/dev-lang/tcl/work/./tcl.h:2186[stdin:1995] /sys/ports/dev-lang/tcl/work/./tommath.h:117[stdin:28483] syntax error, last name: void Before I go further: how are you getting tcl, and if you have patches to it, can you share them? > At first glance it looks like the macro computes the number of bytes > needed to align the address to 16 bytes. But it does not. It should > return either 1 or 2 but it does so only when the address passed in is > XXXX0 or XXXX8. > Yeah. The code is clearly trying to align to 8 bytes, and the way that we did it is broken on 64 bits. While C doesn't guarantee much about pointer alignment, most ABIs do. Patch committed. > The second problem is two fold. In TclExcuteByteCodeObj (or therabouts), > the code keeps track of how much of the stack memory is in use with two > values that are ptrdiff_t. I can't find this code -- it looks like you're looking at a different version of TCL than I am. > IE the high word of the pointer has become corrupted. That also sounds like 32/64 bit issues, where the top of pointers is getting truncated or filled with junk after passing through a 32 bit integer conversion. I *suspect* that they're using ptrdiff_t where they should be using intptr_t, but I don't have the code you're looking at right now.