From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28437 invoked by alias); 3 Feb 2015 03:24:18 -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 28415 invoked by uid 89); 3 Feb 2015 03:24:16 -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,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail.ecoscentric.com Received: from albus.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.200) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 03 Feb 2015 03:24:14 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 50271A831EE; Tue, 3 Feb 2015 03:24:11 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (albus.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH0WL55QyQYg; Tue, 3 Feb 2015 03:24:10 +0000 (GMT) Message-ID: <54D03F59.2000605@eCosCentric.com> Date: Tue, 03 Feb 2015 03:24:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb@sourceware.org Subject: Re: dwarf_block_to_fb_offset() and 64-bit host References: <54C48488.6040100@eCosCentric.com> <20150125082727.GA5745@host1.jankratochvil.net> In-Reply-To: <20150125082727.GA5745@host1.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2015-02/txt/msg00005.txt.bz2 Thanks for all the replies, sorry for the delay in getting back but I haven't been able to work full time on this... On 25/01/15 08:27, Jan Kratochvil wrote: > On Sun, 25 Jan 2015 06:52:08 +0100, Jonathan Larmour wrote: >> In the 32-bit (working) build, in one failing example, fb_offset ends up >> as -28, whereas *fb_offset_return is 0xffffffe4 - this is because >> CORE_ADDR is an *unsigned* 32-bit type (due to bfd_vma). But LONGEST is a >> signed long long - 64-bits - so the comparison between fb_offset and >> *fb_offset_return ends up comparing -28 and 4294967268. So 0 is returned. > > It is not really working. It is just a secondary bug which will omit the > 'id@entry' value to be read/displayed. The primary bug is that reading the > value 'id@entry' errors. After investigation, the reason the read of id@entry failed was because the remote target has provided a memory region map, and the requested stack address to read was 0xffffffff90019160, instead of 0x90019160, therefore lying outside of the permitted memory map, so GDB never even attempted to read from the target. The read of the value came from a call to dwarf2_frame_cache() which calls dwarf2-frame.c:read_reg() which uses unpack_long() which returns a LONGEST which, despite being converted to CORE_ADDR on return, has been sign extended. BUT... what I intended to say in my previous mail but accidentally missed was that this is from GDB 7.6.2. I see that the code in 7.8.2 has changed substantially, now using read_addr_from_reg() which behaves more appropriately for addresses. Indeed, now I've switched to 7.8.2 everything _appears_ to outwardly work okay. However, it now works in the same way that the 32-bit version works, and from the comments in this thread, could there still be a lurking but hidden problem here, because there is still a negative fb_offset of -28? I've tried a variety of different functions and programs, on different ARM targets, and every time fb_offset is negative when reading the frame args. So I have to query whether a negative fb_offset really is a problem. Just in case I was missing something, I thought I would follow Doug Evans' suggestion of changing fb_offset_return to use LONGEST, but not very surprisingly that didn't help the negative fb_offset (Doug's suggestion really being about the discrepancy between 32- and 64-bit host behaviour). Jifl -- Besuchen Sie uns vom 24-26 Feb auf der Embedded World 2015, Stand 4-161 Visit us at Embedded World 2015, Nürnberg-Germany, Stand 4-161, 24-26 Feb eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine