From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22052 invoked by alias); 15 Oct 2009 19:17:14 -0000 Received: (qmail 22044 invoked by uid 22791); 15 Oct 2009 19:17:14 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 19:17:09 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1644D2BAC67; Thu, 15 Oct 2009 15:17:08 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FSTGFeXjE4zi; Thu, 15 Oct 2009 15:17:08 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B0EAE2BABB6; Thu, 15 Oct 2009 15:17:07 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6C6AAF58A0; Thu, 15 Oct 2009 12:16:56 -0700 (PDT) Date: Thu, 15 Oct 2009 19:17:00 -0000 From: Joel Brobecker To: Michael Snyder Cc: "gdb-patches@sourceware.org" , Hui Zhu Subject: Re: [RFA] record.c - save some memory in record log. Message-ID: <20091015191656.GF5272@adacore.com> References: <4AD761AD.40307@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD761AD.40307@vmware.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00354.txt.bz2 > It's based on the observation that the objects that we save > (registers and small memory writes) are frequently the size of > a pointer (or smaller). Therefore, instead of allocating both > a pointer and some malloc memory to hold them, they can simply > be saved in the space used for the pointer itself. One way that we have used in the past that might be helpful here is to define the buffer at the end of the structure and without the pointer indirection: struct blah { ... int buffer_len; gdb_byte buf[0]; }; The allocation of the structure become a little trickier. And access to the buffer is a little more dangerous, which is why I don't like this approach much. But it does save memory, and you can prevent buffer overrun by forcing access to this data through accessor routines... -- Joel