From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41979 invoked by alias); 23 Feb 2017 15:43:08 -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 41963 invoked by uid 89); 23 Feb 2017 15:43:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:dcc9c38, H*MI:sk:dcc9c38, H*f:sk:dcc9c38, realizing 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 ESMTP; Thu, 23 Feb 2017 15:43:06 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2EBFB42BAD; Thu, 23 Feb 2017 15:43:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1NFh49n018103; Thu, 23 Feb 2017 10:43:05 -0500 Subject: Re: [PATCH] Restrict gdb.base/gcore-relro-pie.exp to native/linux targets To: Luis Machado , gdb-patches@sourceware.org References: <1487859197-6269-1-git-send-email-lgustavo@codesourcery.com> <093bd3d5-9723-2412-a736-8f29686d4a8a@redhat.com> <6e1f21a5-3283-b30e-d7fa-e2c1453af882@codesourcery.com> From: Pedro Alves Message-ID: <713c3608-ff65-a940-13d1-afd4da53700c@redhat.com> Date: Thu, 23 Feb 2017 15:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00631.txt.bz2 On 02/23/2017 03:10 PM, Luis Machado wrote: > On 02/23/2017 08:54 AM, Pedro Alves wrote: >> On 02/23/2017 02:47 PM, Luis Machado wrote: >> >>> I still think it doesn't make much sense to run these tests if we're not >>> sure gcore will support them. >> >> I don't understand what you're saying. We can't be sure up >> front. The "gcore" that is run is GDB's "gcore" command. If that >> doesn't work, gdb_gcore_cmd calls unsupported, and the rest of the >> testcase is skipped. >> > > The point is that we are indeed sure this isn't supported, unless we > officially support core files on bare-metal targets (i don't think we > do). There's been talks / patches about adding that for years. Unfortunately it hasn't happened yet, but I think it'd be quite reasonable to have. > See below. Note your patch did not skip the test on bare metal targets. That's not even what the subject says. You've skipped it everywhere but Linux. It's not quite the same thing. > >>> They may run a few early tests/setup >>> tests, but that won't translate into meaningful PASSes. But i'm ok >>> keeping it as-is if others think the early test PASSes are useful. >> >> Looks like it's been useful to catch a startup code problem. ;-) > > Don't you agree this is a clear sign we are really testing something > else other than core file support? Not really. It's a sign that the test is missing a predicate, but it's not "cores work", IMO. The testcase has a few requirements. At least: #1 - PIEs make sense for this target. #2 - gcore works To me this is a clear sign a predicate for #1 is missing. We already detect #2. Other tests build PIEs too. IOW, IMO, all this talk about core files is a distraction from the real issue. But then I wonder why does compilation, linking, loading all succeed without something realizing the binary can't run on this target. It may well be that PIEs do make sense for this target. It's not uncommon to call things "bare-metal" when they're really pretty sophisticated RTOSs. > It just means a proper standalone > test doesn't exist to catch such a problem and we got lucky crashing > when doing a core file test on a target that doesn't support it. It is > not like the test was designed to catch this. > > I find it a bit messy. A proper test would attempt to run pie > executables to completion (and i can contribute that to verify this > particular problem). How would that help, if it'd crash and loop the board too? > I just don't like the concept of running a test that is unsupported on a > particular target (core files) only to test a side-effect during > pre-test/setup phases. It only adds to artificial PASSes that don't > necessarily translate to robustness. > > But i understand if this is not acceptable. I just want to clean this > target up, and seeing core file tests being executed is just confusing. :-) Thanks, Pedro Alves