From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1792 invoked by alias); 10 Nov 2008 20:25:09 -0000 Received: (qmail 1770 invoked by uid 22791); 10 Nov 2008 20:25:08 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout2.012.net.il (HELO mtaout2.012.net.il) (84.95.2.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Nov 2008 20:24:26 +0000 Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KA400F00WLTH900@i_mtaout2.012.net.il> for gdb-patches@sourceware.org; Mon, 10 Nov 2008 22:26:12 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.241.172]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KA4002BGWRN7BV1@i_mtaout2.012.net.il>; Mon, 10 Nov 2008 22:26:12 +0200 (IST) Date: Mon, 10 Nov 2008 20:45:00 -0000 From: Eli Zaretskii Subject: Re: [RFA] Process record and replay, 9/10 In-reply-to: <20081110144014.GA12962@caradoc.them.org> X-012-Sender: halo1@inter.net.il To: Daniel Jacobowitz Cc: teawater@gmail.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: 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/msg00193.txt.bz2 > 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.