From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109404 invoked by alias); 23 Feb 2017 16:16:33 -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 109169 invoked by uid 89); 23 Feb 2017 16:16:32 -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,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=worthy, H*f:sk:713c360, H*i:sk:713c360, H*MI:sk:713c360 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Feb 2017 16:16:30 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1cgw4C-0000F6-KG from Luis_Gustavo@mentor.com ; Thu, 23 Feb 2017 08:16:28 -0800 Received: from [172.30.12.171] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 08:16:23 -0800 Reply-To: Luis Machado Subject: Re: [PATCH] Restrict gdb.base/gcore-relro-pie.exp to native/linux targets References: <1487859197-6269-1-git-send-email-lgustavo@codesourcery.com> <093bd3d5-9723-2412-a736-8f29686d4a8a@redhat.com> <6e1f21a5-3283-b30e-d7fa-e2c1453af882@codesourcery.com> <713c3608-ff65-a940-13d1-afd4da53700c@redhat.com> To: Pedro Alves , From: Luis Machado Message-ID: <7b8b7c00-c2e4-9a7f-9738-990a4e4be351@codesourcery.com> Date: Thu, 23 Feb 2017 16:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <713c3608-ff65-a940-13d1-afd4da53700c@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-02.mgc.mentorg.com (147.34.90.202) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00634.txt.bz2 On 02/23/2017 09:43 AM, Pedro Alves wrote: > 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. I find it reasonable too, but it is not here yet. > 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. This is just a stack pointer startup problem, so not a matter of supporting PIE's or not. > How would that help, if it'd crash and loop the board too? > The test would need to be tweaked. The assumption that these targets can handle a crash is not always valid as it is with OS-based targets. I remember i addressed problems with these assumptions in the past. It is similar to assuming reading 0x0 would error out or that it is a bad address. We are much more aware of that problem these days. Unfortunately not a lot of bare-metal/RTOS testing going on for gdb at the moment. I think even QEMU shields these tests from problems sometimes. Anyway, i know what i have to do to get this FAIL fixed! The discussion about how focused/robust a particular gdb test is/needs to be can be rather long. At this point i don't think there is a lot of benefit from that, but maybe a worthy discussion in the future about how to improve gdb's testsuite, or not!