From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14411 invoked by alias); 22 Feb 2007 14:57:25 -0000 Received: (qmail 14403 invoked by uid 22791); 22 Feb 2007 14:57:25 -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:57:14 +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 l1MEvBTM272644 for ; Thu, 22 Feb 2007 14:57:11 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 l1MEvAOv1327194 for ; Thu, 22 Feb 2007 15:57:10 +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 l1MEvA7K002183 for ; Thu, 22 Feb 2007 15:57:10 +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 l1MEvAw1002180; Thu, 22 Feb 2007 15:57:10 +0100 Message-ID: <45DDAF29.9000105@de.ibm.com> Date: Thu, 22 Feb 2007 14:57: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: multipart/mixed; boundary="------------020908030101030407070301" 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/msg00263.txt.bz2 This is a multi-part message in MIME format. --------------020908030101030407070301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 737 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 --------------020908030101030407070301 Content-Type: text/plain; name="diff-fix-valops" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff-fix-valops" Content-length: 505 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; --------------020908030101030407070301--