From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103085 invoked by alias); 28 Feb 2017 00:36:26 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 103047 invoked by uid 89); 28 Feb 2017 00:36:24 -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=Tracking 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; Tue, 28 Feb 2017 00:36:23 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1ciVm9-0000Aq-Ec from Luis_Gustavo@mentor.com ; Mon, 27 Feb 2017 16:36:21 -0800 Received: from [172.30.12.6] (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; Mon, 27 Feb 2017 16:36:18 -0800 Subject: Re: Question about backtraces through signal handlers for aarch64 ILP32 support References: <1488241574.2866.227.camel@caviumnetworks.com> To: Steve Ellcey , gdb From: Luis Machado Reply-To: Luis Machado Message-ID: <1fb132ae-4230-2ae1-ad57-6ca51b1c8d97@codesourcery.com> Date: Tue, 28 Feb 2017 00:36: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: <1488241574.2866.227.camel@caviumnetworks.com> Content-Type: text/plain; charset="utf-8"; 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/msg00057.txt.bz2 On 02/27/2017 06:26 PM, Steve Ellcey wrote: > I am working on supporting gdb on aarch64 in ILP32 mode but am not that > familiar with gdb and was wondering if anyone could give me some ideas > on where to look for a problem I am seeing. > > I run the test case 'gdb.base/sigstep' in gdb by hand and do the initial > commands that that testsuite does: > > break main > run > break handler > continue > bt > > In LP64 mode, I get this backtrace: > > #0 handler (sig=26) > at /home/ubuntu/sellcey/gdb-ilp32/obj-64/binutils/gdb/testsuite/../../../.. > /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:35 > #1 > #2 0x00000000004008cc in main () > at /home/ubuntu/sellcey/gdb-ilp32/obj-64/binutils/gdb/testsuite/../../../.. > /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:87 > > But in ILP32 mode, I get this backtrace: > > #0 handler (sig=26) > at /home/ubuntu/sellcey/gdb-ilp32/obj-32/binutils/gdb/testsuite/../../../.. > /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:35 > #1 > #2 0x00000000 in ?? () > #3 0x00400740 in main () > at /home/ubuntu/sellcey/gdb-ilp32/obj-32/binutils/gdb/testsuite/../../../.. > /src/binutils-gdb/gdb/testsuite/gdb.base/sigstep.c:87 > > > I think the backtrace for ILP32 does not match what is expected because > it has the extra entry in it (#2 with no name or location). I am not sure > if that is a real frame that the test needs to expect or just an error in > how gdb is reading the frame information. Not a real entry AFAICS. > > Normal backtraces seem to be working fine, the majority of ILP32 failures > I get in gdb.base (that don't also happen in LP64 mode) are tests with 'sig' > in their name like sigstep. > > Any ideas on where to look or what to look for? That extra frame indicates gdb is getting confused when extracting register state from the signal frame and creates a spurious frame at 0x0. Maybe gdb is finding a frame pointer that points to 0x0 and should instead point to 0x00400740 (main)? Tracking that down may help figure it out. Otherwise the backtrace looks sane.