From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75864 invoked by alias); 23 Feb 2017 14:25:02 -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 75802 invoked by uid 89); 23 Feb 2017 14:25:01 -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=earth, our 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 14:25:00 +0000 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9C7D4811A9; Thu, 23 Feb 2017 14:25:00 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id B22DEB7D30; Thu, 23 Feb 2017 14:24:59 +0000 (UTC) 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> From: Pedro Alves Message-ID: <093bd3d5-9723-2412-a736-8f29686d4a8a@redhat.com> Date: Thu, 23 Feb 2017 14:25: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: <1487859197-6269-1-git-send-email-lgustavo@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00620.txt.bz2 On 02/23/2017 02:13 PM, Luis Machado wrote: > This particular test doesn't work correctly on aarch64-elf for a couple > reasons. > > First, the test is supposed to crash and bare-metal targets are not always > ready to handle such exceptions like Linux does. In our case the board just > keeps cycling within an ISR function. Hmm? AFAICS, the testcase is generating the core with gdb_gcore_cmd. How on earth is that causing this cycling? Either I'm missing something, or the reason for the cycling is something else, like for example, the fact that the test is compiled with flags (-fpie -pie Wl,-z,relro) that might generate a binary that does not work correctly, or strip is broken for that target, or something like that. Thanks, Pedro Alves