From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4142 invoked by alias); 25 Jan 2015 05:54:34 -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 3681 invoked by uid 89); 25 Jan 2015 05:53:55 -0000 Authentication-Results: sourceware.org; auth=none 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; Sun, 25 Jan 2015 05:52:54 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 80EBDA8AD77 for ; Sun, 25 Jan 2015 05:52:29 +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 SL0MwPcLCKdY; Sun, 25 Jan 2015 05:52:29 +0000 (GMT) Message-ID: <54C48488.6040100@eCosCentric.com> Date: Sun, 25 Jan 2015 08:03: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: gdb@sourceware.org Subject: dwarf_block_to_fb_offset() and 64-bit host Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-01/txt/msg00071.txt.bz2 Hi folks, I've been looking at a problem on a remote Cortex-M target, which notably happens to have a somewhat atypical property of using an address space of 0x9xxxxxxx - in other words, addresses will have the top bit set. When debugging, there is a problem with a GDB built for a 64-bit host, versus one built for 32-bit, all from exactly the same source base. It manifests with this sort of issue with a 64-bit hosted GDB: Breakpoint 2, fileio1_main (id=0, id@entry=) at /.../fatfs1.c:431 The cited address is perfectly valid and readable. Whereas on a 32-bit GDB: Breakpoint 2, fileio1_main (id=0) at /.../fatfs1.c:431 I have tracked down where the 32-bit and 64-bit builds of GDB diverge in behaviour and it's in dwarf2expr.c's dwarf_block_to_fb_offset(): int dwarf_block_to_fb_offset (const gdb_byte *buf, const gdb_byte *buf_end, CORE_ADDR *fb_offset_return) { int64_t fb_offset; [snip] buf++; buf = gdb_read_sleb128 (buf, buf_end, &fb_offset); if (buf == NULL) return 0; *fb_offset_return = fb_offset; if (buf != buf_end || fb_offset != (LONGEST) *fb_offset_return) return 0; return 1; } 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. 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. I'm unsure about where the bug really lies. I'm not familiar enough with Dwarf, but I have to wonder why there's the test for "fb_offset != (LONGEST) *fb_offset_return" in the first place. Any help/advice from anyone with Dwarf experience would be welcome, thanks. Jifl -- ------["Si fractum non sit, noli id reficere"]------ Opinions==mine