From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28931 invoked by alias); 1 Sep 2009 08:57:13 -0000 Received: (qmail 28912 invoked by uid 22791); 1 Sep 2009 08:57:11 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f188.google.com (HELO mail-px0-f188.google.com) (209.85.216.188) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Sep 2009 08:57:04 +0000 Received: by pxi26 with SMTP id 26so505787pxi.13 for ; Tue, 01 Sep 2009 01:57:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.129.2 with SMTP id g2mr57524wfn.56.1251795422134; Tue, 01 Sep 2009 01:57:02 -0700 (PDT) In-Reply-To: <83hbvo9blv.fsf@gnu.org> References: <837hwzir3w.fsf@gnu.org> <8363cefkkp.fsf@gnu.org> <83fxbhdofo.fsf@gnu.org> <83skfecvmz.fsf@gnu.org> <83hbvo9blv.fsf@gnu.org> From: Hui Zhu Date: Tue, 01 Sep 2009 08:57:00 -0000 Message-ID: Subject: Re: [RFA/RFC Prec] Add process record skip 6/6 (doc) To: Eli Zaretskii Cc: gdb-patches@sourceware.org, msnyder@vmware.com, green@moxielogic.com Content-Type: multipart/mixed; boundary=000e0cd5f67477c21a0472805544 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: 2009-09/txt/msg00014.txt.bz2 --000e0cd5f67477c21a0472805544 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 6033 On Tue, Sep 1, 2009 at 00:44, Eli Zaretskii wrote: >> From: Hui Zhu >> 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=3DISO-8859-1 >> Content-Transfer-Encoding: quoted-printable >> >> On Thu, Aug 27, 2009 at 01:50, Eli Zaretskii wrote: >> >> From: Hui Zhu >> >> 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? =3DA0In that case, we should docume= nt >> >> > 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? =A0Why >> > 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. =A0Nor did anyone else; am I the only > one who is bothered by the ad-hoc nature of such design? > Sorry I forgot it. I think this idea is not bad. But when user set a simple_function to GDB, check if this function is really a simple function or not is not easy. What about keep this idea and add special patch for it when gdb support record skip? >> > Also, why is this code being make Linux-specific? =3DA0Surely, 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. =A0And they will change >> different memory and reg. > > Are you talking in general, or are you talking about the x86 > architecture? =A0I think all x86 implementations of `printf' and > `memset' will use the same ABI, certainly those that use GCC as the > native compiler. Yes, I think they are same in 32 bits. But x86 is special, it need support amd64 too. It's 64 bits and have another different registers. So.. I think the arch developer can call "record_skip_entry_create" in the place that he like. > >> +The record skip entry is a special breakpoint. =A0When the process >> +record and replay target start, it will be inserted to the >> +begin of a function. =A0When this breakpoint break the inferior and > =A0 ^^^^^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0^^^^^ =A0 =A0 =A0 =A0 =A0 =A0 ^^^^ > =A0 "beginning" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0"breaks" =A0 =A0 =A0 =A0 =A0", if" > >> +@value{GDBN} is in record mode, @value{GDBN} will skip record all > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "refrain from recording" > >> +the execution log of this function's instructions and record the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "and only record" > >> +change of memory and registers of this function as one instruction. > =A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > =A0 "modifications of memory and registers by this function" > >> +Show the status of record skip. > > =A0 "This command shows the status of record skipping." > >> +@item record skip disable @r{[}id@r{]} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "@var{id}" > >> +@item record skip enable @r{[}id@r{]} > > Likewise. > > OK with these changes. > > Thanks. > I make a new patch according to your comments. Please help me review it. Thanks, Hui --- doc/gdb.texinfo | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) --- a/doc/gdb.texinfo +++ b/doc/gdb.texinfo @@ -5214,6 +5214,31 @@ When record target runs in replay mode ( subsequent execution log and begin to record a new execution log starting from the current address. This means you will abandon the previously recorded ``future'' and begin recording a new ``future''. + +@kindex record skip +@kindex rec skip +@item record skip +The record skip entry is a special breakpoint. When the process +record and replay target start, it will be inserted to the +beginning of a function. When this breaks break, if +@value{GDBN} is in record mode, refrain from recording skip record all +the execution log of this function's instructions and only record the +modifications of memory and registers by this function. +This command shows the status of record skipping. + +Only some standard functions are currently supported by the +@code{record skip} command; type the command without arguments to +see the full list. + +@kindex record skip disable +@kindex rec skip disable +@item record skip disable @var{id} +Disable the specified record skip entry (or all record skip entries). + +@kindex record skip enable +@kindex rec skip enable +@item record skip enable @var{id} +Enable the specified record skip entry (or all record skip entries). @end table --000e0cd5f67477c21a0472805544 Content-Type: text/plain; charset=US-ASCII; name="6-skip-record-doc.txt" Content-Disposition: attachment; filename="6-skip-record-doc.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fz2et4n80 Content-length: 1875 LS0tCiBkb2MvZ2RiLnRleGluZm8gfCAgIDI1ICsrKysrKysrKysrKysrKysr KysrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCAyNSBpbnNlcnRpb25zKCspCgot LS0gYS9kb2MvZ2RiLnRleGluZm8KKysrIGIvZG9jL2dkYi50ZXhpbmZvCkBA IC01MjE0LDYgKzUyMTQsMzEgQEAgV2hlbiByZWNvcmQgdGFyZ2V0IHJ1bnMg aW4gcmVwbGF5IG1vZGUgKAogc3Vic2VxdWVudCBleGVjdXRpb24gbG9nIGFu ZCBiZWdpbiB0byByZWNvcmQgYSBuZXcgZXhlY3V0aW9uIGxvZyBzdGFydGlu ZwogZnJvbSB0aGUgY3VycmVudCBhZGRyZXNzLiAgVGhpcyBtZWFucyB5b3Ug d2lsbCBhYmFuZG9uIHRoZSBwcmV2aW91c2x5CiByZWNvcmRlZCBgYGZ1dHVy ZScnIGFuZCBiZWdpbiByZWNvcmRpbmcgYSBuZXcgYGBmdXR1cmUnJy4KKwor QGtpbmRleCByZWNvcmQgc2tpcAorQGtpbmRleCByZWMgc2tpcAorQGl0ZW0g cmVjb3JkIHNraXAKK1RoZSByZWNvcmQgc2tpcCBlbnRyeSBpcyBhIHNwZWNp YWwgYnJlYWtwb2ludC4gIFdoZW4gdGhlIHByb2Nlc3MKK3JlY29yZCBhbmQg cmVwbGF5IHRhcmdldCBzdGFydCwgaXQgd2lsbCBiZSBpbnNlcnRlZCB0byB0 aGUKK2JlZ2lubmluZyBvZiBhIGZ1bmN0aW9uLiAgV2hlbiB0aGlzIGJyZWFr cyBicmVhaywgaWYKK0B2YWx1ZXtHREJOfSBpcyBpbiByZWNvcmQgbW9kZSwg cmVmcmFpbiBmcm9tIHJlY29yZGluZyBza2lwIHJlY29yZCBhbGwKK3RoZSBl eGVjdXRpb24gbG9nIG9mIHRoaXMgZnVuY3Rpb24ncyBpbnN0cnVjdGlvbnMg YW5kIG9ubHkgcmVjb3JkIHRoZQorbW9kaWZpY2F0aW9ucyBvZiBtZW1vcnkg YW5kIHJlZ2lzdGVycyBieSB0aGlzIGZ1bmN0aW9uLgorVGhpcyBjb21tYW5k IHNob3dzIHRoZSBzdGF0dXMgb2YgcmVjb3JkIHNraXBwaW5nLgorCitPbmx5 IHNvbWUgc3RhbmRhcmQgZnVuY3Rpb25zIGFyZSBjdXJyZW50bHkgc3VwcG9y dGVkIGJ5IHRoZQorQGNvZGV7cmVjb3JkIHNraXB9IGNvbW1hbmQ7IHR5cGUg dGhlIGNvbW1hbmQgd2l0aG91dCBhcmd1bWVudHMgdG8KK3NlZSB0aGUgZnVs bCBsaXN0LgorCitAa2luZGV4IHJlY29yZCBza2lwIGRpc2FibGUKK0BraW5k ZXggcmVjIHNraXAgZGlzYWJsZQorQGl0ZW0gcmVjb3JkIHNraXAgZGlzYWJs ZSBAdmFye2lkfQorRGlzYWJsZSB0aGUgc3BlY2lmaWVkIHJlY29yZCBza2lw IGVudHJ5IChvciBhbGwgcmVjb3JkIHNraXAgZW50cmllcykuCisKK0BraW5k ZXggcmVjb3JkIHNraXAgZW5hYmxlCitAa2luZGV4IHJlYyBza2lwIGVuYWJs ZQorQGl0ZW0gcmVjb3JkIHNraXAgZW5hYmxlIEB2YXJ7aWR9CitFbmFibGUg dGhlIHNwZWNpZmllZCByZWNvcmQgc2tpcCBlbnRyeSAob3IgYWxsIHJlY29y ZCBza2lwIGVudHJpZXMpLgogQGVuZCB0YWJsZQogCiAK --000e0cd5f67477c21a0472805544--