From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11041 invoked by alias); 10 Nov 2008 21:22:32 -0000 Received: (qmail 11012 invoked by uid 22791); 10 Nov 2008 21:22:31 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Nov 2008 21:21:55 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 028282200A; Mon, 10 Nov 2008 13:21:53 -0800 (PST) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost5.vmware.com (Postfix) with ESMTP id E8A91DC056; Mon, 10 Nov 2008 13:21:52 -0800 (PST) Message-ID: <4918A406.3020400@vmware.com> Date: Mon, 10 Nov 2008 23:02:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii CC: Daniel Jacobowitz , "teawater@gmail.com" , "gdb-patches@sourceware.org" Subject: Re: [RFA] Process record and replay, 9/10 References: <20081110144014.GA12962@caradoc.them.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2008-11/txt/msg00199.txt.bz2 Eli Zaretskii wrote: >> Date: Mon, 10 Nov 2008 09:40:14 -0500 >> From: Daniel Jacobowitz >> Cc: teawater , gdb-patches@sourceware.org >> >> On Sat, Nov 08, 2008 at 11:24:52AM +0200, Eli Zaretskii wrote: >>> I understand that. I was asking whether we should store this >>> information in the same place where we store all the other info about >>> Linux system calls, not in the source. >> Ideally, yes, I agree. But this is type layout rather than system >> call information, and we haven't designed a way to store it in the >> system call database yet. I'm sure we will at some point, but perhaps >> we should address that afterwards instead of waiting? > > I'm fine with doing it later, if we can live with having the info in > two places in the meantime. Yes, I think later is good.