From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19219 invoked by alias); 8 Jun 2008 06:53:45 -0000 Received: (qmail 19207 invoked by uid 22791); 8 Jun 2008 06:53:44 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.190) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 08 Jun 2008 06:53:18 +0000 Received: by ti-out-0910.google.com with SMTP id d10so444363tib.12 for ; Sat, 07 Jun 2008 23:53:15 -0700 (PDT) Received: by 10.110.11.1 with SMTP id 1mr469151tik.2.1212907995026; Sat, 07 Jun 2008 23:53:15 -0700 (PDT) Received: by 10.110.109.4 with HTTP; Sat, 7 Jun 2008 23:53:14 -0700 (PDT) Message-ID: Date: Sun, 08 Jun 2008 06:53:00 -0000 From: teawater To: "Pedro Alves" , gdb-patches@sourceware.org Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release Cc: "Michael Snyder" , "Thiago Jung Bauermann" In-Reply-To: <200805231746.23570.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200805221737.50773.pedro@codesourcery.com> <200805231746.23570.pedro@codesourcery.com> 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-06/txt/msg00131.txt.bz2 Cool. This idea is so cool. In before, I tried to make clear about the "strata", but I gave up. Now, I know this thing is so cool. But it let me very puzzled that which way is the best. The way that I used in before, I have done a a lot of things on it. And it can be used. The way that use a special target for record, I think this way look professional. Please tell me your idea about it. Thanks a lot. BTW, I realse record 0.1.4 and 0.1.5. Please give me you advice about it. http://sourceware.org/ml/gdb-patches/2008-05/msg00692.html http://sourceware.org/ml/gdb-patches/2008-06/msg00041.html Thanks, teawater On Sat, May 24, 2008 at 00:46, Pedro Alves wrote: > > A Friday 23 May 2008 03:54:06, Tea wrote: > > Hi Pedro, > > I am not very clear your meaning. Could you please write a example for me? > > Sure, I'll try. > > Think of the target stack roughly as polimorphism. Each layer > of the stack overrides methods of the layer beneath. A stratum > concept is used because there is a layering order on the stack, where > a given target implementation can sit at. E.g., a thread_stratum layer > target always sits above a process_stratum layer target. The > file_stratum is always below the process_stratum. When core GDB wants > to wait for a debug event, it calls target_wait. E.g, on linux native > debugging, that ends up calling linux_nat_wait on non multi-threaded > applications. If your new target is the topmost on the stack, then > record_wait would be called instead. > > There's some description of it in the gdbint manual in > the "Target Vector Definition" node, but it isn't much complete. > There are more comments describing the struture in target.h. > > As I said, if you make "record" sit on the target vector, then a > call to target_wait (), would really be calling record_wait (), > e.g., > > ptid_t > record_wait (ptid_t ptid, struct target_waitstatus *ourstatus) > { > if (record_list && (record_list->next || gdb_is_reverse))) > { > ... do whatever you were doing in record_wait ... > } > else > return t->beneath->to_wait (ptid, outstatus); > } > > Same for target_mourn_inferior, and target_close, at least. > > See remote.c:init_remote_ops, and any struct target_ops > instance in GDB (like remote_ops in remote.c) for examples, > or perhaps a more staightforward one as win32-nat.c:win32_ops. > > Issuing the "record" command would push the record target on > the stack, and stoprecord would pop it, and normally > target_mourn_inferior and target_detach do it too, although you > probably want to be able to shift to reverse after a > process death. The new stratum suggestion was so it always sits > above all the others (see target.c:push_target) > > record_ops.to_stratum = above_all_or_whatever_new_stratum; > record_ops.to_wait = record_wait; > > /* record resume would be were you call record_message. */ > record_ops.to_resume = record_resume; > > /* Calls record_close, and pops target record off the stack. */ > record_ops.to_mourn_inferior = record_mourn_inferior; > > etc. > > At a first glimpse it looks desirable to go this path. > You may get around to even abstract more things that you're doing > in infrun.c. Take this only as an investigation suggestion. > > -- > Pedro Alves