From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 745 invoked by alias); 22 Feb 2007 14:33:56 -0000 Received: (qmail 726 invoked by uid 22791); 22 Feb 2007 14:33:55 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 22 Feb 2007 14:33:42 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l1MEXdXi038864 for ; Thu, 22 Feb 2007 14:33:39 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1MEXdfD1957938 for ; Thu, 22 Feb 2007 15:33:39 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1MEXd9i029264 for ; Thu, 22 Feb 2007 15:33:39 +0100 Received: from [9.152.248.45] (dyn-9-152-248-45.boeblingen.de.ibm.com [9.152.248.45]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1MEXdsi029258; Thu, 22 Feb 2007 15:33:39 +0100 Message-ID: <45DDA9A6.7040502@de.ibm.com> Date: Thu, 22 Feb 2007 14:33:00 -0000 From: Markus Deuling User-Agent: Thunderbird 1.5.0.9 (X11/20061215) MIME-Version: 1.0 To: GDB Patches CC: Ulrich Weigand Subject: Patch: Fix handling for TYPE_CODE_INT in valops.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2007-02/txt/msg00255.txt.bz2 Hi, I've seen errors when debugging a SPU target. Accessing e.g. a variable by its address failes: (gbd) p test_var $2 = 5 (gdb) x/x &test_var 0x2b50 : 0x00000005 (gdb) p *0x2b50 Cannot access memory at address 0x2b50 The architecture specific callback integer_to_address() isn't called, so that's why in this case 0x2b50 isn't converted to a combined address as it should. The patch calls value_as_address instead of value_as_long to handle a TYPE_CODE_INT. Running the test suite showed no regressions both on x86 and SPU. Ok to commit ? ChangeLog: * valops.c (value_ind): Fix unary * handling of TYPE_CODE_INT. Regards, Markus -- Markus Deuling GNU Toolchain for Linux on Cell BE deuling@de.ibm.com ======================================================= diff -urN src/gdb/valops.c dev/gdb/valops.c --- src/gdb/valops.c 2007-01-09 18:58:59.000000000 +0100 +++ dev/gdb/valops.c 2007-02-22 14:41:04.000000000 +0100 @@ -934,7 +934,7 @@ BUILTIN_TYPE_LONGEST would seem to be a mistake. */ if (TYPE_CODE (base_type) == TYPE_CODE_INT) return value_at_lazy (builtin_type_int, - (CORE_ADDR) value_as_long (arg1)); + (CORE_ADDR) value_as_address (arg1)); else if (TYPE_CODE (base_type) == TYPE_CODE_PTR) { struct type *enc_type;