Re: GDB record patch 0.1.3.1 for GDB-6.8 release

[teawater <teawater at gmail dot com>]

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 <pedro@codesourcery.com> 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