From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7000 invoked by alias); 13 Nov 2006 19:40:16 -0000 Received: (qmail 6988 invoked by uid 22791); 13 Nov 2006 19:40:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Nov 2006 19:40:07 +0000 Received: (qmail 16505 invoked from network); 13 Nov 2006 19:40:06 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 13 Nov 2006 19:40:06 -0000 To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org Subject: Re: [RFA][1/5] New port: Cell BE SPU (dwarf2loc.c fix) References: <200611111837.kABIbcwQ031159@d12av02.megacenter.de.ibm.com> From: Jim Blandy Date: Mon, 13 Nov 2006 19:40:00 -0000 In-Reply-To: <200611111837.kABIbcwQ031159@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Sat, 11 Nov 2006 19:37:38 +0100 (CET)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00103.txt.bz2 "Ulrich Weigand" writes: > this fixes a problem in dwarf2loc.c that triggers for the SPU port. > > The code in dwarf_expr_read_reg currently expects that in order to > retrieve an address value from a register, it's OK to assume the > address can always be extracted using extract_unsigned_integer > on the full size of the register. > > This fails on the SPU, because all registers are 16 bytes wide, and > a pointer is represented by simply using the uppermost 4 bytes and > ignoring the contents of the remaining 12 bytes. I would assume > that there's also other architectures where the assumption in > dwarf_expr_read_reg might fail, e.g. due to sign extension issues > or other required fiddling. > > So, to fix this I thought that we already *know* how to extract > values of a certain type from a register: value_from_register does > just that, and provides all sorts of configurability for the back > end to have it just do the right thing. Since the value retrieved > by dwarf_expr_read_reg is always a pointer to some data object > (normally on the stack), it should be OK to get it by using > value_from_register (builtin_type_void_data_ptr, ...). > > This is what the patch below does, and it works fine on SPU. > Additionally tested without regressions on s390-ibm-linux and > s390x-ibm-linux. This seems fine. I tested it on i686 Fedora Core 5 and didn't see any new failures. Would it be a good idea to introduce a new function, a companion to value_from_register, that wraps up the composition of value_from_register and value_as_address?