From: teawater <teawater@gmail.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb-patches@sourceware.org, Michael Snyder <msnyder@vmware.com>
Subject: Re: [RFA] Submit process record and replay third time, 3/9
Date: Fri, 13 Mar 2009 00:27:00 -0000 [thread overview]
Message-ID: <daef60380903121657w3dc82bdai8ae16b47aa4dd3c3@mail.gmail.com> (raw)
In-Reply-To: <daef60380903101637y6a88c74cl39a90852400e62d9@mail.gmail.com>
Hi Pedro,
Sorry to disturb you.
Could you please help me review it?
Thanks,
Hui
On Wed, Mar 11, 2009 at 07:37, teawater <teawater@gmail.com> wrote:
> Hi Pedro,
>
> On Wed, Mar 11, 2009 at 02:00, Pedro Alves <pedro@codesourcery.com> wrote:
>> On Tuesday 10 March 2009 17:02:46, teawater wrote:
>>> >> +#define TARGET_IS_PROCESS_RECORD \
>>> >> + (current_target.beneath == &record_ops)
>>> >
>>> > Sorry, but I repeat the request I've made several times already. This is
>>> > not the right way to do this. You need to add a new target_ops method or
>>> > property that the core of GDB checks on. It is not correct that make
>>> > the core of GDB reference record_ops directly. To come up with
>>> > the target callback's name, at each call site of TARGET_IS_PROCESS_RECORD,
>>> > consider what is the property of the current target that GDB needs to
>>> > know about the current target. Is it something like:
>>> >
>>> > target_is_recording () ?
>>> > target_is_replaying () ?
>>> > target_is_read_only () ?
>>> >
>>> > etc.
>>> >
>>>
>>> I forget a process record has special strata "record_stratum".
>>>
>>> What about delete "TARGET_IS_PROCESS_RECORD" and add
>>> #define target_is_record (target) (target->to_stratum == record_stratum)
>>> to target.h?
>>
>> No, that's not a new callback...
>>
>> If we in some hypothetical future end up layering yet another target
>> on top of record, then that check will fail.
>>
>> What I'm saying is, TARGET_IS_PROCESS_RECORD is just as wrong
>> as TARGET_IS_LINUX_NAT_C, or TARGET_IS_WINDOWS_NAT_C.
>>
>> E.g., in places in the common code that we want to check if the
>> current target has execution, we call target_has_execution, doesn't
>> matter which target it is, as long as it has execution. If we want to
>> check that the target is in asynchronous more, we check for
>> target_is_async_p, again, doesn't matter which target it is.
>>
>> In your case, imagine that you implemented all of record.c in
>> gdbserver instead of on GDB. Say, imagine that there's no record.c in
>> GDB at all. Then, when you connected to gdbserver, and told it to
>> start recording, the topmost pushed target on the GDB side would still be
>> the remote target (process stratum). GDB wouldn't know how gdbserver
>> was implementing the recording feature, only that the remote side supports
>> the recording feature. Now, see, here's a property we'd possibly
>> want to expose through a target method --- e.g., target_can_record_p().
>>
>> If you look at the places in the core of GDB where you are
>> currently checking for TARGET_IS_PROCESS_RECORD, and you wanted those
>> checks to also return true in the case of precord being implemented
>> on the remote server, clearly, you'd need to check for some
>> target property other than the target name, or its stratum.
>>
>> Why is it that you need to call TARGET_IS_PROCESS_RECORD in the
>> first place? That is the key here. Again, is it because the
>> target is recording, and you can't do some things in that case?
>> Is it because the target is replaying? Or perhaps it's a more
>> fundamental state --- is the target in a read only state? When you
>> find out which *state(s)* you're interesting in checking, we can
>> easily add target method(s) for it/them, and make the record
>> target implement them (say, returning true), and making the
>> default return false. Or, we may even come to the conclusion
>> that is not a target method we want --- we may end up with
>> a global variable, similar to `execution_direction'.
>>
>
> TARGET_IS_PROCESS_RECORD is not very well. I agree with it.
> Let's talk about "#define target_is_record (target)
> (target->to_stratum == record_stratum)".
>
> If add a new callback, it's mean that every target can be a process
> record or not.
> But process record is not a function, it's a target.
> For example:
> static int
> use_displaced_stepping (struct gdbarch *gdbarch)
> {
> return (((can_use_displaced_stepping == can_use_displaced_stepping_auto
> && non_stop)
> || can_use_displaced_stepping == can_use_displaced_stepping_on)
> && gdbarch_displaced_step_copy_insn_p (gdbarch)
> && !TARGET_IS_PROCESS_RECORD);
> }
>
> This place use "TARGET_IS_PROCESS_RECORD" because process record
> target can't work with displaced stepping.
>
> if (TARGET_IS_PROCESS_RECORD)
> old_cleanups = record_gdb_operation_disable_set ();
>
> if (singlestep_breakpoints_inserted_p
> || !ptid_equal (ecs->ptid, inferior_ptid)
> || !currently_stepping (ecs->event_thread)
> || ecs->event_thread->prev_pc == breakpoint_pc)
> regcache_write_pc (regcache, breakpoint_pc);
>
> if (TARGET_IS_PROCESS_RECORD)
> do_cleanups (old_cleanups);
>
> This place use "TARGET_IS_PROCESS_RECORD" because process record don't
> want record this pc change.
>
> Off course, in global code call a macro in record.h is ugly. I agree.
>
> But "#define target_is_process_record (target) (target->to_stratum ==
> record_stratum)". is better.
> record_stratum is in enum strata
> {
> dummy_stratum, /* The lowest of the low */
> file_stratum, /* Executable files, etc */
> core_stratum, /* Core dump files */
> process_stratum, /* Executing processes */
> thread_stratum, /* Executing threads */
> record_stratum /* Support record debugging */
> };
> in target.h.
> It's used to make process record on the top of all other target. Just
> process record use it.
> I think it friendly to both global code and process record target.
>
>
> Thanks,
> Hui
>
next prev parent reply other threads:[~2009-03-12 23:57 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-08 5:46 teawater
2009-01-13 3:06 ` teawater
2009-01-20 18:32 ` Marc Khouzam
2009-01-20 19:47 ` Marc Khouzam
2009-01-21 0:20 ` teawater
2009-01-21 2:53 ` teawater
2009-01-22 13:23 ` Pedro Alves
2009-01-22 15:23 ` teawater
2009-01-22 22:33 ` Pedro Alves
2009-01-22 22:36 ` Pedro Alves
2009-01-23 0:00 ` teawater
2009-01-23 6:58 ` teawater
2009-01-23 14:56 ` teawater
2009-01-23 15:34 ` Pedro Alves
2009-01-23 15:55 ` teawater
2009-02-02 9:05 ` teawater
2009-02-08 13:03 ` teawater
2009-02-17 7:12 ` teawater
2009-02-17 7:21 ` teawater
2009-02-23 16:05 ` teawater
2009-03-03 20:40 ` Pedro Alves
2009-03-04 3:42 ` teawater
2009-03-09 6:01 ` teawater
2009-03-09 19:31 ` Pedro Alves
2009-03-10 17:03 ` teawater
2009-03-09 20:35 ` Pedro Alves
2009-03-10 17:32 ` teawater
2009-03-10 19:35 ` Pedro Alves
2009-03-11 1:15 ` teawater
2009-03-13 0:27 ` teawater [this message]
2009-03-16 11:21 ` teawater
2009-03-18 8:50 ` teawater
2009-03-18 13:12 ` teawater
2009-03-18 13:05 ` teawater
2009-03-18 13:14 ` teawater
2009-03-18 13:54 ` teawater
2009-02-23 14:08 ` teawater
2009-02-28 10:02 ` teawater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=daef60380903121657w3dc82bdai8ae16b47aa4dd3c3@mail.gmail.com \
--to=teawater@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=msnyder@vmware.com \
--cc=pedro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox