From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15812 invoked by alias); 25 Jan 2015 08:27:47 -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 15776 invoked by uid 89); 25 Jan 2015 08:27:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 25 Jan 2015 08:27:36 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0P8RWVD022823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 25 Jan 2015 03:27:32 -0500 Received: from host1.jankratochvil.net (ovpn-116-113.ams2.redhat.com [10.36.116.113]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0P8RS3g014346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 25 Jan 2015 03:27:31 -0500 Date: Sun, 25 Jan 2015 08:32:00 -0000 From: Jan Kratochvil To: Jonathan Larmour Cc: gdb@sourceware.org Subject: Re: dwarf_block_to_fb_offset() and 64-bit host Message-ID: <20150125082727.GA5745@host1.jankratochvil.net> References: <54C48488.6040100@eCosCentric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C48488.6040100@eCosCentric.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00073.txt.bz2 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. > In the 64-bit (buggy) build, fb_offset is still -28 but *fb_offset_return > is 0xffffffffffffffe4 (CORE_ADDR now being an unsigned 64-bit type), which > when cast to LONGEST (which is signed) is still -28. Therefore 1 is > returned. This later results in read_frame_arg()'s call to > ops->read_variable_at_entry incorrectly believing there is a different > value of the variable on entry. To find out whether there is or isn't a different value one has to read it first. Which for an unknown reason fails in your case. If the id entry value was equal GDB would print: Breakpoint 2, fileio1_main (id=id@entry=0) at /.../fatfs1.c:431 which happens in neither of your case. The primary problem is why GDB fails to read the address 0x9001917c. It usually happens that GDB tries to read address like 0x19001917c or address 0xffffffff9001917c while then the error report return xstrprintf (_("Cannot access memory at address %s"), paddress (gdbarch, memaddr)); strips the upper bits in paddress(). corefile.c:memory_error_message(): s/paddress (gdbarch, memaddr)/core_addr_to_string (memaddr)/ may reveal that. Jan