From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16931 invoked by alias); 30 Dec 2014 09:20:13 -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 16908 invoked by uid 89); 30 Dec 2014 09:20:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 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, 30 Dec 2014 09:20:09 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Y5syE-0003Q6-DC from Yao_Qi@mentor.com ; Tue, 30 Dec 2014 01:20:06 -0800 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Tue, 30 Dec 2014 01:20:06 -0800 From: Yao Qi To: Pedro Alves CC: Subject: Re: [PATCH] Clear upper bits during sign extension References: <1419815569-21854-1-git-send-email-yao@codesourcery.com> <54A13184.1070902@redhat.com> Date: Tue, 30 Dec 2014 09:20:00 -0000 In-Reply-To: <54A13184.1070902@redhat.com> (Pedro Alves's message of "Mon, 29 Dec 2014 10:48:36 +0000") Message-ID: <874msdwl39.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00677.txt.bz2 Pedro Alves writes: > 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. indirect_pieced_value is called by value_ind, in which its argument ARG1 should be regarded as an address, IMO. #0 indirect_pieced_value (value=3D0x8af0fd8) at ../../../git/gdb/dwarf2loc= .c:2006 #1 0x081d99fa in value_ind (arg1=3D0x8af0fd8) at ../../../git/gdb/valops.c= :1548 #2 0x081de7f2 in value_subscript (array=3D0x8b41678, index=3D-2) at ../../= ../git/gdb/valarith.c:181 See value_ind's comment: /* Given a value of a pointer type, apply the C unary * operator to it. */ struct value * value_ind (struct value *arg1) > > E.g., I don't see how it makes sense to interpret -2 as an address > on spu, which ends up calling: -2 is *not* the address in this case. The address is 0xfffffffe, and sign extended to 64-bit (0xfffffffffffffffe) on MIPS target. > > static CORE_ADDR > spu_integer_to_address (struct gdbarch *gdbarch, > struct type *type, const gdb_byte *buf) > { > int id =3D spu_gdbarch_id (gdbarch); > ULONGEST addr =3D unpack_long (type, buf); > > return SPUADDR (id, addr); > } Sorry, I don't understand how is gdbarch_integer_to_address hook related to this problem. The address (0xfffffffe) is the address of synthetic pointer, instead of the actual address. --=20 Yao (=E9=BD=90=E5=B0=A7)