From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4837 invoked by alias); 7 Apr 2013 10:41:47 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 4826 invoked by uid 89); 7 Apr 2013 10:41:47 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sun, 07 Apr 2013 10:41:44 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 328114680008 for ; Sun, 7 Apr 2013 11:41:42 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-WnYnO79QzP; Sun, 7 Apr 2013 11:41:37 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001814] Kinetis clock gating Date: Sun, 07 Apr 2013 10:41:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg00031.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814 --- Comment #21 from Ilija Kocho --- (In reply to comment #20) > I printed out dlmalloc.cxx before I retired for the day and read some of the > description. I can't understand how this code with the large malloc ever > worked. Given the 26K heap, and the allocation up to 4K chunks, no chunk > should ever have been large enough unless it can append chunks, which my > understanding is that it can't do that. > > Given that, I don't think I have any choice but to rewrite my algorithm to > use a 4K buffer. > > So I can't find any reason not to commit this code, even if it breaks my > code. > > However, if anyone has any idea how it could have worked, please enlighten > me. Mike If the buffer is permanent, you may use staticaly allocated array. Also, FYI Cortex-M specification requires stack to be 8 Byte aligned (though I haven't experienced any anomaly with 4 Byte alignment so far). Ilija -- You are receiving this mail because: You are on the CC list for the bug.