From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5091 invoked by alias); 7 May 2009 22:52:20 -0000 Received: (qmail 5080 invoked by uid 22791); 7 May 2009 22:52:19 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 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.43rc1) with ESMTP; Thu, 07 May 2009 22:52:10 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id ACC6F3E00C; Thu, 7 May 2009 15:52:06 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id A21CBC9E0F; Thu, 7 May 2009 15:52:06 -0700 (PDT) Message-ID: <4A036401.6060906@vmware.com> Date: Thu, 07 May 2009 22:52:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pierre Muller CC: 'Hui Zhu' , "gdb-patches@sourceware.org" Subject: Re: Process record and replay checked in to main trunk References: <001201c9cf62$8e2761a0$aa7624e0$@u-strasbg.fr> In-Reply-To: <001201c9cf62$8e2761a0$aa7624e0$@u-strasbg.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: 2009-05/txt/msg00165.txt.bz2 Guessing it isn't implemented for 64 bit. Perhaps we should have a --disable-process-record config option? If only for a back-up plan? Pierre Muller wrote: > Your patch seems to break multi build for cygwin: > > If I configure with --enable-targets=all and --enable-64-bits-bfd > > > gcc -gstabs+ -O0 -I. -I../../purecvs/gdb -I../../purecvs/gdb/common > -I../../pu > recvs/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H > -I../ > ../purecvs/gdb/../include/opcode -I../../purecvs/gdb/../readline/.. -I../bfd > -I. > ./../purecvs/gdb/../bfd -I../../purecvs/gdb/../include -I../libdecnumber > -I../.. > /purecvs/gdb/../libdecnumber -I../../purecvs/gdb/gnulib -Ignulib > -DMI_OUT=1 -D > TUI=1 -Wall -Wdeclaration-after-statement -Wpointer-arith > -Wformat-nonliteral > -Wno-unused -Wno-switch -Wno-char-subscripts -Werror -c -o linux-record.o > -MT li > nux-record.o -MMD -MP -MF .deps/linux-record.Tpo > ../../purecvs/gdb/linux-record. > c > ../../purecvs/gdb/linux-record.c: In function `record_linux_system_call': > ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t > arg > (arg 2) > ../../purecvs/gdb/linux-record.c:397: warning: unsigned int format, uint32_t > arg > (arg 2) > ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg > 3) > ../../purecvs/gdb/linux-record.c:629: warning: int format, uint32_t arg (arg > 3) > ../../purecvs/gdb/linux-record.c:938: warning: unsigned int format, uint32_t > arg > (arg 2) > ../../purecvs/gdb/linux-record.c:938: warning: unsigned int format, uint32_t > arg > (arg 2) > ../../purecvs/gdb/linux-record.c:1636: error: `F_GETLK64' undeclared (first > use > in this function) > ../../purecvs/gdb/linux-record.c:1636: error: (Each undeclared identifier is > rep > orted only once > ../../purecvs/gdb/linux-record.c:1636: error: for each function it appears > in.) > ../../purecvs/gdb/linux-record.c:1642: error: `F_SETLK64' undeclared (first > use > in this function) > ../../purecvs/gdb/linux-record.c:1643: error: `F_SETLKW64' undeclared (first > use > in this function) > ../../purecvs/gdb/linux-record.c:1789: warning: int format, long int arg > (arg 4) > > ../../purecvs/gdb/linux-record.c:2199: warning: unsigned int format, > uint32_t ar > g (arg 2) > ../../purecvs/gdb/linux-record.c:2199: warning: unsigned int format, > uint32_t ar > g (arg 2) > make[1]: *** [linux-record.o] Error 1 > make[1]: Leaving directory `/usr/local/src/gdbcvs/multibuild/gdb' > make: *** [all-gdb] Error 2 > > > Maybe it is out of scope to support reverse debugging of > linux code for remote target, but would it then be possible > to avoid that this source gets compiled? > > > Pierre Muller > Pascal language support maintainer for GDB > > >> -----Message d'origine----- >> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la >> part de Hui Zhu >> Envoyé : Thursday, April 30, 2009 10:02 AM >> À : gdb ml >> Cc : Pedro Alves; Marc Khouzam; Michael Snyder; Thiago Jung Bauermann; >> Eli Zaretskii; Mark Kettenis >> Objet : Process record and replay checked in to main trunk >> >> Hi guys, >> >> Process record and replay make gdb can record inferior execute log and >> replay (include reverse debug). >> Now, it support I386-Linux single-thread single-inferior native debug. >> >> >> It was checked in today. >> Thanks for evey people that spent time on process record. Precord >> can't be a part of gdb without your help. Thank you very much. :) >> >> >> And precord still has a long way to go. There have a lot of thing need >> to do: >> >> 1. Support i386 more better. Now, precord doesn't support mmx insns, >> support fp insns not very well and doesn't support a lot of insns. >> >> 2. Support more arches. X86-64 is the first one (linux-record.c). >> MIPS, ARM and so on. >> >> 3. Support memory free better. Now, precord just can output a warning >> for memumap. It can do nothing when there is a sys_brk to free the >> memory. >> I had make a patch to output a warning when there is a sys_brk to free >> the memory and make a plan to make precord can support free memory. >> I will keep work on it. >> >> 4. Support multi-thread and multi-inferior. >> I remember Pedro make a patch for reverse debug resume. I think we >> need this patch when multi-inferior check in. >> >> 5. Make record speed up and need less memory. >> I have made a plan to make p record doesn't record execution log of >> some functions (It can set), for example some functions in glibc. >> >> 6. Make execution log can dump out to be a file and can replay for next >> time. >> Maybe it can make together with coredump support. It must be a cool >> function. :) >> >> Guys, please work on it if you interesting with some of them. And >> feel free tell me your ideas and comments. It will help precord a >> lot. >> >> >> Thanks, >> Hui >