From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91574 invoked by alias); 12 Aug 2015 19:59:53 -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 91561 invoked by uid 89); 12 Aug 2015 19:59:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 12 Aug 2015 19:59:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C0FE129066; Wed, 12 Aug 2015 15:59:50 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1-x3mnPFkcYG; Wed, 12 Aug 2015 15:59:50 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 868F928F8C; Wed, 12 Aug 2015 15:59:50 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id A61A046993; Wed, 12 Aug 2015 12:59:48 -0700 (PDT) Date: Wed, 12 Aug 2015 19:59:00 -0000 From: Joel Brobecker To: Luis Machado Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH v4 00/18] All-stop on top of non-stop Message-ID: <20150812195948.GH22245@adacore.com> References: <1432250354-2721-1-git-send-email-palves@redhat.com> <55C4E3BD.8040801@redhat.com> <20150812183208.GA24901@adacore.com> <55CBA0D1.5000203@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55CBA0D1.5000203@codesourcery.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-08/txt/msg00320.txt.bz2 > Two things about the patch. I see that the change to GDB's code is almost > trivial, but the testcase looks quite involved. > > The first thing is that one wouldn't be able to tell what the testcase does > without looking at the commit log. dso2dso doesn't particularly translate to > "displaced stepping instruction masking problem on amd64". Should we change > the testcase name to something a bit more meaningful? Maybe document it a > bit? > > The second point is, should we restrict this testcase to be executed only > for amd64? Maybe move it to gdb.arch? Unless you actually tried this > testcase with different architectures and confirmed the testcase is sane > there, it feels a bit iffy to add/execute this for non-amd64 targets. > > In the worst case, we could have a failure due to different instruction > scheduling schemes (or maybe even a displaced stepping bug) on non-amd64 > targets. At a minimum, we'd have a spurious PASS that wouldn't be meaningful > for the overall test results since things never failed on said architecture > in the first place. > > Alternatively, for such a trivial fix, shouldn't we go without a testcase? Some good points. To me, the purpose of the test is to verify that stepping from some code in one DSO over a call to a function in another DSO, is working on all platforms that support shared libraries. That's the main purpose of the test. If, one day, the implementation changes so that displaced stepping is no longer necessary, then what matters at the user level is that this testcase continues to behave the same. Even if you wanted a gdb.arch test that verified this specific bug, you'd have to find a way for the test to load at an address that's high enough that the mask starts causing problems. I don't think that's very easy, and I'm not sure it's worth our time. Regarding the complexity of the test, I think we need to try it and see. At AdaCore, we run the equivalent Ada testcase nightly on Linux (x86, x86_64 and ppc), Windows (x86 and x86_64), Solaris (sparc) and Darwin (x86_64), and it passes everywhere. It passes with GDBserver too. My take would be that we'd be fixing trivial errors in the testcase itself, and just accept the failures on platforms where it reveals a bona fide issue, as we've beeing doing with all the other tests. -- Joel