From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96469 invoked by alias); 9 Jan 2017 15:22:43 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 96459 invoked by uid 89); 9 Jan 2017 15:22:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2069, energia, joe X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jan 2017 15:22:41 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65BFFC057872 for ; Mon, 9 Jan 2017 15:22:41 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-116-16.ams2.redhat.com [10.36.116.16]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v09FMeub026009 for ; Mon, 9 Jan 2017 10:22:41 -0500 Received: by calimero.vinschen.de (Postfix, from userid 500) id 983BFA8041E; Mon, 9 Jan 2017 16:22:39 +0100 (CET) Date: Mon, 09 Jan 2017 15:22:00 -0000 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: [PATCH 1/2] Fix incorrect cast in nano malloc Message-ID: <20170109152239.GC4007@calimero.vinschen.de> Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-SW-Source: 2017/txt/msg00015.txt.bz2 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2093 On Jan 3 14:50, Joe Seymour wrote: > As described in nano-mallocr.c, chunks of heap are represented in memory > as a size (of type long), followed by some optional padding containing a > negative offset to size, followed by the data area. >=20 > get_chunk_from_ptr is responsible for taking a pointer to the data area > (as returned by malloc) and finding the start of the chunk. It does this > by assuming there is no padding and trying to read the size, if the size > is negative then it uses that as an offset to find the true size. > Crucially, it reads the padding area as a long. >=20 > nano_malloc is responsible for populating the optional padding area. It > does so by casting a pointer to an (int *) and writing the negative > offset into it. >=20 > This means that padding is being written as an int but read as a long. >=20 > On msp430 an int is 2 bytes, while a long is 4 bytes. This means that 2 > bytes are written to the padding, but 4 bytes are read from it: it has > only been partially initialised. >=20 > nano_malloc is the default malloc implementation for msp430. >=20 > This patch changes the cast from (int *) to (long *). The change to > nano_malloc has has been observed to fix a TI Energia project that > had been malfunctioning because malloc was returning invalid addresses. > The change to nano_memalign is based entirely on code inspection. >=20 > I've built and tested as follows: > Configured (gcc+newlib) with: --target=3Dmsp430-elf --enable-languages= =3Dc > gcc testsuite variations: > msp430-sim/-mcpu=3Dmsp430 > msp430-sim/-mcpu=3Dmsp430x > msp430-sim/-mcpu=3Dmsp430x/-mlarge/-mdata-region=3Deither/-mcode-regi= on=3Deither > msp430-sim/-mhwmult=3Dnone > msp430-sim/-mhwmult=3Df5series > My testing has shown no regressions, however I don't know if the gcc > testsuite provides sufficient coverage for this patch? >=20 > I don't have write access, so if this patch is acceptable after review, > I would appreciate it if someone would commit it for me. Applied. Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer Red Hat --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYc6q/AAoJEPU2Bp2uRE+g0egP/RgJsItNfsraNbD1zXYwmdxk KKKqVg+Gy4P5+MZ6TDEasWcEO0ig9NSujpO4KgwxYP1fQUiBA7l4m+QXrUPVSFpV JPbp0MD0ch57JySY+JVXuBIqPu2h1PllEhxSvBojIH4HTMVuEWtSFpuQKLo33nib YDJu+Flyi0Pm+41PDIlGEJWrrxpAZv/ST7B92MpxnHX/vC2v/8GoZOSr3B2FueaU DXD+nYR+1mXbAg8N8kco/N6Eu4fo3ZsH12uMcKkq2AW0h/2AHUbUM/3IJiw0DfIU vGrIq7e9wLX5m68k+m9VFE3J1vgMTHtn9MFWKZ3cUbfNZjwrZjETXIhPNUtRSZHQ 9yjJVABkfWu5J3hXKcDMgAHOKsjRig8hljEqgMQo3/Z6KOqCS34ax+1fvlct/QpW +MLcQr0Rpoo7VglpttvjJRA8xR+P+pWJZpXjNcqq3ZLtDVgOP3JPcEedouGEgn0p pmI7YGSw9JIOQOWYF2pgIFiA/2cPGdXwujheYWtTblwJlsJ7geyfXPTrq4BZrr+k YgRE+NKHD9eISv/R5M9qlMJp6aYRVRPgAg0A6d4Go91iLlEF1GZ+HiwIsOXqPy/T m0v54jX0TRrSiB8VQeJYYQsH1kAVIbtq/79YnopHsK1ZvmDviiWOtVGFA1DG1IQq XRxUJiGVwLtJSEFA0C0B =cyTS -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT--