Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Hui Zhu <teawater@gmail.com>
Cc: gdb-patches@sourceware.org, msnyder@vmware.com, green@moxielogic.com
Subject: Re: [RFA/RFC Prec] Add process record skip 6/6 (doc)
Date: Mon, 31 Aug 2009 17:41:00 -0000	[thread overview]
Message-ID: <83hbvo9blv.fsf@gnu.org> (raw)
In-Reply-To: <daef60380908310626q41dfee5al987dbeac3d60ee03@mail.gmail.com>

> From: Hui Zhu <teawater@gmail.com>
> Date: Mon, 31 Aug 2009 21:26:04 +0800
> Cc: gdb-patches@sourceware.org, msnyder@vmware.com, green@moxielogic.com
> 
> --000e0cd72d34f48d8004726ffae8
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, Aug 27, 2009 at 01:50, Eli Zaretskii<eliz@gnu.org> wrote:
> >> From: Hui Zhu <teawater@gmail.com>
> >> Date: Tue, 25 Aug 2009 11:47:09 +0800
> >> Cc: gdb-patches@sourceware.org, msnyder@vmware.com, green@moxielogic.com
> >>
> >> >> i386_linux_process_record_simple_function is for printf.
> >> >> i386_linux_process_record_memset is for memset and memcpy.
> >> >
> >> > So we currently support record skip of only 3 functions, the ones
> >> > mentioned above, is that right? =A0In that case, we should document
> >> > those functions in the manual, I think.
> >>
> >> Yes, I think after this feature in, we can add more and more functions
> >> to support skip.
> >
> > But then the proposed code is IMHO awfully limited, isn't it?  Why
> > not add some more general mechanism, for several broad classes of
> > functions (like the `simple_function' class you used for `printf'),
> > and let the user specify which functions she wants to skip, instead of
> > hard-coding the functions in GDB?
> >
> > By contrast, the suggested code will cause us to have gobs of library
> > functions intimately known to GDB, and will bloat the executable, for
> > starters.

You didn't answer these concerns.  Nor did anyone else; am I the only
one who is bothered by the ad-hoc nature of such design?

> > Also, why is this code being make Linux-specific? =A0Surely, most, if
> > not all, other implementations of `printf', `memset' and `memcpy' have
> > the exact same API and the same external effects as those you have in
> > glibc, no?
> 
> The api is same, but the ABI for each arch and os is not same, each
> printf, memset or memcpy of each arch-os will get the argument from
> different memory and different register.  And they will change
> different memory and reg.

Are you talking in general, or are you talking about the x86
architecture?  I think all x86 implementations of `printf' and
`memset' will use the same ABI, certainly those that use GCC as the
native compiler.

> +The record skip entry is a special breakpoint.  When the process
> +record and replay target start, it will be inserted to the
> +begin of a function.  When this breakpoint break the inferior and
   ^^^^^                                      ^^^^^             ^^^^
   "beginning"                                "breaks"          ", if"

> +@value{GDBN} is in record mode, @value{GDBN} will skip record all
                                                     ^^^^^^^^^^^^^^^
                                                     "refrain from recording"

> +the execution log of this function's instructions and record the
                                                     ^^^^^^^^^^
                                                     "and only record"

> +change of memory and registers of this function as one instruction.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   "modifications of memory and registers by this function"

> +Show the status of record skip.

   "This command shows the status of record skipping."

> +@item record skip disable @r{[}id@r{]}
                                  ^^
                                 "@var{id}"

> +@item record skip enable @r{[}id@r{]}

Likewise.

OK with these changes.

Thanks.


  reply	other threads:[~2009-08-31 16:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-19  8:15 Hui Zhu
2009-08-19 18:45 ` Eli Zaretskii
2009-08-23  3:52   ` Hui Zhu
2009-08-23 22:48     ` Eli Zaretskii
2009-08-24  9:53       ` Hui Zhu
2009-08-24 19:14         ` Eli Zaretskii
2009-08-25  4:25           ` Hui Zhu
2009-08-26 17:54             ` Eli Zaretskii
2009-08-31 13:59               ` Hui Zhu
2009-08-31 17:41                 ` Eli Zaretskii [this message]
2009-09-01  8:57                   ` Hui Zhu
2009-09-01 17:12                     ` Eli Zaretskii
2009-09-02 12:01                       ` Hui Zhu

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=83hbvo9blv.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=green@moxielogic.com \
    --cc=msnyder@vmware.com \
    --cc=teawater@gmail.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