From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3054 invoked by alias); 21 Aug 2007 09:57:49 -0000 Received: (qmail 2885 invoked by uid 22791); 21 Aug 2007 09:57:48 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Aug 2007 09:57:43 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l7L9vedA248572 for ; Tue, 21 Aug 2007 09:57:40 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.5) with ESMTP id l7L9veUr2314314 for ; Tue, 21 Aug 2007 11:57:40 +0200 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 l7L9veGK017004 for ; Tue, 21 Aug 2007 11:57:40 +0200 Received: from bbkeks.boeblingen.de.ibm.com (dyn-9-152-248-39.boeblingen.de.ibm.com [9.152.248.39]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7L9vdEY016995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 11:57:40 +0200 Message-ID: <46CAB6B7.30806@de.ibm.com> Date: Tue, 21 Aug 2007 09:57:00 -0000 From: Markus Deuling User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Ulrich Weigand CC: Daniel Jacobowitz , Jim Blandy , GDB Patches Subject: Re: [rfc] Wrap addresses in spu-gdb References: <200708201842.l7KIg16S028544@d12av02.megacenter.de.ibm.com> In-Reply-To: <200708201842.l7KIg16S028544@d12av02.megacenter.de.ibm.com> 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-08/txt/msg00409.txt.bz2 Hi, Ulrich Weigand schrieb: > Well, I'm seeing these regressions: actually. I must have overseen these two. > FAIL: gdb.cp/cp-relocate.exp: break *'int func<1>(int)' > FAIL: gdb.cp/cp-relocate.exp: break *'int func<2>(int)' > Could you investigate those? In the gdb.cp/cp-relocate.exp testcase "add-symbol-file" tries to load two sections of an objfile at hard-wired addresses 0x40000 and 0x80000. Within SPU these addresses are wrapped to the size of the Local Store (which is btw 0x40000 :-) ) so 0x40000 and 0x80000 are wrapped to 0x0. break *'int func<1>(int)'^M Breakpoint 1 at 0x40: file ../../../src/gdb/testsuite/gdb.cp/cp-relocate.cc, line 21.^M (gdb) FAIL: gdb.cp/cp-relocate.exp: break *'int func<1>(int)' break *'int func<2>(int)'^M Breakpoint 2 at 0x68: file ../../../src/gdb/testsuite/gdb.cp/cp-relocate.cc, line 21.^M (gdb) FAIL: gdb.cp/cp-relocate.exp: break *'int func<2>(in As seen here the original addresses of the two functions (detected in the beginning of the testcase: 0x40 and 0x68) remain as addresses for the functions. The arent replaced by 0x0. If the testcase addresses are changed to, for example, 0x40100 and 0x80100 the wrapping produces addresses <> 0x0. Now the adresses for the functions are set (correctly): break *'int func<1>(int)'^M Breakpoint 1 at 0x100: file ../../../src/gdb/testsuite/gdb.cp/cp-relocate.cc, line 21.^M (gdb) FAIL: gdb.cp/cp-relocate.exp: break *'int func<1>(int)' break *'int func<2>(int)'^M Note: breakpoint 1 also set at pc 0x100.^M Breakpoint 2 at 0x100: file ../../../src/gdb/testsuite/gdb.cp/cp-relocate.cc, line 21.^M (gdb) FAIL: gdb.cp/cp-relocate.exp: break *'int func<2>(int)' In this case both are set to 0x100 which is correct for SPU: (0x40100 % SPU_LS_SIZE) == (0x80100 % SPU_LS_SIZE) == 0x100. So there are three issues: 1) Should add-symbol-file set the function address to -in this case- 0x0 ? SPU hardware would handle both 0x40000 and 0x80000 as 0x0. 2) As seen in my example "add-symbol-file" loads two functions to the same addresses 0x100. Is this valid? 3) Should the used addresses in the testcase be changed to, for example, 0x10000 and 0x20000? This would work for SPU, too. Or shall I introduce variables for this addresses and set them to a range < SPU_LS_SIZE for SPU targets only? What do you think? -- Markus Deuling GNU Toolchain for Linux on Cell BE deuling@de.ibm.com