From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79192 invoked by alias); 20 Oct 2015 11:07:34 -0000 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 Received: (qmail 76716 invoked by uid 89); 20 Oct 2015 11:07:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 20 Oct 2015 11:07:32 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 5DE45461C3; Tue, 20 Oct 2015 11:07:30 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9KB7R9v029850; Tue, 20 Oct 2015 07:07:27 -0400 Message-ID: <5626206E.1000405@redhat.com> Date: Tue, 20 Oct 2015 11:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?TWFyY2luIEtvxZtjaWVsbmlja2k=?= , Yao Qi CC: gdb-patches@sourceware.org Subject: Re: gdb/linux-record fixes References: <1445118081-10908-1-git-send-email-koriakin@0x04.net> <56250E2D.7020009@redhat.com> <562525C1.7000205@0x04.net> In-Reply-To: <562525C1.7000205@0x04.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2015-10/txt/msg00348.txt.bz2 On 10/19/2015 06:17 PM, Marcin Kościelnicki wrote: > Yeah, they're not covered by the testsuite. Actually, there seem to be > only two tests in gdb.reverse suite that even touch syscalls: > sigall-reverse (signal, sigprocmask, exit_group) and watch-reverse > (read, write). No wonder that syscall handling is buggy... > > Stepping forward and backward over pipe/time/waitpid would indeed do the > trick for patch #6. Can I convince you to add that to the patch (and likewise to others that might not be overly hard)? BTW, you'll also need to include ChangeLog entries. Please check here: https://sourceware.org/gdb/wiki/ContributionChecklist > Some others are trickier to test, though - for > example to test #3 (overlong sigaction/sigset_t) you'd need to manually > invoke the actual linux syscalls, taking care to pull the right struct > definitions from kernel headers, and make sure they're located near the > end of segment bounduary (so that accessing after the end causes an > error) - the glibc wrappers will always allocate relevant structs on > stack, which almost certainly has extra bytes after the struct, hiding > the bug. OOC, how did you first notice the bug? > > BTW, I was thinking of a self-testing approach for linux-record: > > - if gdb debugging is enabled, record changes on each instruction twice: > before and after execution > - memory/register contents recorded in "before" stage should match > contents previously recorded in "after" stage, if any (ie. if it's not > the first time we see a register or a memory byte). If there's a > mismatch, record missed something. > > Unfortunately, that's a non-starter for multithreaded programs, or for > progams involving shared memory :( Sounds like a good idea. I don't see multithreading being an issue, as target record doesn't really work with multithreaded programs to begin with. Also, I don't think we'd want it behind the usual "set debug record" knob, as that sounds like it could actually change the record target's behavior, and heisenbugs. Probably put it under its own "maint set record self-check on" or some such knob. This reminds me that Yao once wrote a test that did something like that (registers only, no gdb magic): https://sourceware.org/ml/gdb-patches/2015-05/msg00482.html Not sure what happened to that. Thanks, Pedro Alves