From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27728 invoked by alias); 11 Nov 2008 05:43:24 -0000 Received: (qmail 27705 invoked by uid 22791); 11 Nov 2008 05:43:24 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.189) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 11 Nov 2008 05:42:46 +0000 Received: by ti-out-0910.google.com with SMTP id d10so1812604tib.12 for ; Mon, 10 Nov 2008 21:42:43 -0800 (PST) Received: by 10.110.16.9 with SMTP id 9mr8871137tip.6.1226382163591; Mon, 10 Nov 2008 21:42:43 -0800 (PST) Received: by 10.110.103.3 with HTTP; Mon, 10 Nov 2008 21:42:43 -0800 (PST) Message-ID: Date: Tue, 11 Nov 2008 13:21:00 -0000 From: teawater To: "Eli Zaretskii" Subject: Re: [RFA] Process record and replay, 9/10 Cc: "Daniel Jacobowitz" , gdb-patches@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081110144014.GA12962@caradoc.them.org> 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/msg00209.txt.bz2 OK. I will do it later. On Tue, Nov 11, 2008 at 04:24, 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. >