From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8200 invoked by alias); 29 Dec 2014 10:48:54 -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 8186 invoked by uid 89); 29 Dec 2014 10:48:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 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; Mon, 29 Dec 2014 10:48:52 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBTAmmwp017124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Dec 2014 05:48:49 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBTAmbc1012035; Mon, 29 Dec 2014 05:48:43 -0500 Message-ID: <54A13184.1070902@redhat.com> Date: Mon, 29 Dec 2014 10:48:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] Clear upper bits during sign extension References: <1419815569-21854-1-git-send-email-yao@codesourcery.com> In-Reply-To: <1419815569-21854-1-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00660.txt.bz2 On 12/29/2014 01:12 AM, Yao Qi wrote: > I see the error message "access outside bounds of object referenced > via synthetic pointer" in the two fails below of mips gdb testing > > print d[-2]^M > access outside bounds of object referenced via synthetic pointer^M > (gdb) FAIL: gdb.dwarf2/implptrconst.exp: print d[-2] > (gdb) print/d p[-1]^M > access outside bounds of object referenced via synthetic pointer^M > (gdb) FAIL: gdb.dwarf2/implptrpiece.exp: print/d p[-1] > > in the first test, 'd[-2]' is processed by GDB as '* (&d[-2])'. 'd' > is a synthetic pointer, so its value is zero, the address of 'd[-2]' > is -2. In dwarf2loc.c:indirect_pieced_value, > > /* This is an offset requested by GDB, such as value subscripts. > However, due to how synthetic pointers are implemented, this is > always presented to us as a pointer type. This means we have to > sign-extend it manually as appropriate. */ > byte_offset = value_as_address (value); <---- [1] > if (TYPE_LENGTH (value_type (value)) < sizeof (LONGEST)) > byte_offset = gdb_sign_extend (byte_offset, <---- [2] > 8 * TYPE_LENGTH (value_type (value))); > byte_offset += piece->v.ptr.offset; > > on MIPS target, after [1], byte_offset is -2 (0xfffffffffffffffe), > because 32-bit -2 (as an address) is sign extended to 64-bit. After > [2], we manually sign extend byte_offset too, and then it becomes > 0xfffffffefffffffe, which is wrong. Function gdb_sign_extend > sign-extends VALUE on bit BIT, and assumes upper bits from bit BIT are > all zero. That is why the code works well on targets on which address > is zero extended, such as x86. On these targets, byte_offset is > 0xfffffffe (zero extended from 32-bit address -2). > > The patch is to clear upper bits of VALUE in gdb_sign_extend first. > Regression tested on mips-linux-gnu, and fixes two fails above. This seems to me to paper over an issue elsewhere, and is likely to paper over issues as gdb_sign_extend is used more throughout. I'm not immediately familiar with all the conditions indirect_pieced_value is called, but going by the comment quoted, I think the root issue might be that we shouldn't use value_as_address in the first place, but something like unpack_long directly. E.g., I don't see how it makes sense to interpret -2 as an address on spu, which ends up calling: static CORE_ADDR spu_integer_to_address (struct gdbarch *gdbarch, struct type *type, const gdb_byte *buf) { int id = spu_gdbarch_id (gdbarch); ULONGEST addr = unpack_long (type, buf); return SPUADDR (id, addr); } or on avr, which ends up calling: static CORE_ADDR avr_integer_to_address (struct gdbarch *gdbarch, struct type *type, const gdb_byte *buf) { ULONGEST addr = unpack_long (type, buf); return avr_make_saddr (addr); } ... /* SRAM address checks and convertions. */ static CORE_ADDR avr_make_saddr (CORE_ADDR x) { /* Return 0 for NULL. */ if (x == 0) return 0; return ((x) | AVR_SMEM_START); } ... AVR_SMEM_START = 0x00800000, /* SRAM memory */ ... Thanks, Pedro Alves