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.
next prev parent 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