From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24755 invoked by alias); 3 Aug 2007 04:06:08 -0000 Received: (qmail 24747 invoked by uid 22791); 3 Aug 2007 04:06:05 -0000 X-Spam-Check-By: sourceware.org Received: from nwd2mail10.analog.com (HELO nwd2mail10.analog.com) (137.71.25.55) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 03 Aug 2007 04:05:59 +0000 Received: from nwd2mhb1.analog.com ([137.71.5.12]) by nwd2mail10.analog.com with ESMTP; 03 Aug 2007 00:05:56 -0400 X-IronPort-AV: i="4.19,215,1183348800"; d="scan'208"; a="47271117:sNHT36906835" Received: from nwd2exm4.ad.analog.com (nwd2exm4.ad.analog.com [10.64.53.123]) by nwd2mhb1.analog.com (8.9.3 (PHNE_28810+JAGae91741)/8.9.3) with ESMTP id AAA20056 for ; Fri, 3 Aug 2007 00:05:56 -0400 (EDT) Received: from nwd2exm5.ad.analog.com ([10.64.51.20]) by nwd2exm4.ad.analog.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Aug 2007 00:05:56 -0400 Received: from localhost ([10.64.204.110]) by nwd2exm5.ad.analog.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Aug 2007 00:05:56 -0400 From: Robin Getz To: gdb@sourceware.org Subject: debugging something with multiple text sections in one compilation unit Date: Fri, 03 Aug 2007 04:06:00 -0000 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708030009.46899.rgetz@blackfin.uclinux.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00018.txt.bz2 Hi. On the Blackfin target there is some on chip L1 SRAM (both instruction and data) which runs at core clock speeds (600MHz+) - which is at a fixed address. When we running uCLinux on Blackfin (it is noMMU), we give people the ability to put part of their user space application into this L1 space (function by function, via a compiler attribute). This adds a new section ('l1_text' and 'l1_data') to the elf file. The offset of the text and l1_text sections is determined at run time, since we don't know where the application will go in physical memory, or where things will be located in L1 (it is dynamic, depending on what other things are allocated there). As far as we can tell - there seems to be a limitation in DWARF spec (or DWARF implementation of gcc/gdb) - there seems to be only only one single base address. All other addresses are an offset to that base in the same compilation unit. When we use l1_text attribute, we have two code segments in one compilation unit and the offset between them is determined only when it's loaded. So one segment cannot get symbol addresses computed correctly - and we can not set breakpoints in functions that are in L1, and debugging applications is pretty difficult. Any thoughts or suggestions? Thanks in advance.... -Robin What we get today (to fill in more of the details): With the following code: #include #include void bar (int i) __attribute__ ((l1_text)); void bar (int i) { printf("i = %i\n",i); } int main () { int i; i = 1; printf("Goodbye world - %i\n",i); bar(i); return 0; } Compile and copy to the board - bfin-linux-uclibc-gcc foo.c -o foo objdump -d shows the function bar is in L1 (which starts at ffa00000). ffa00000 <_bar>: ffa00000: 00 e8 03 00 LINK 0xc; ffa00004: b8 b0 [FP+0x8]=R0; ffa00006: 18 e4 09 00 R0=[P3+0x24]; ffa0000a: b9 a0 R1=[FP+0x8]; ffa0000c: 1a e4 12 00 R2=[P3+0x48]; ffa00010: 12 32 P2=R2; ffa00012: 51 91 P1=[P2]; ffa00014: 53 ac P3=[P2+0x4]; ffa00016: 61 00 CALL (P1); ffa00018: 01 e8 00 00 UNLINK; ffa0001c: 10 00 RTS; GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-linux-uclibc"... (gdb) tar remote 10.64.204.96:2000 Remote debugging using 10.64.204.96:2000 0x00389160 in ?? () (gdb) break bar Cannot access memory at address 0xffde7800 (gdb) break main Note: breakpoint 1 also set at pc 0x32ee48. Breakpoint 2 at 0x32ee48: file foo.c, line 13. (gdb) c Continuing. Breakpoint 1, main () at foo.c:13 13 i = 1; (gdb) s 14 printf("Goodbye world - %i\n",i); (gdb) s 15 bar(i); (gdb) stepi 0x0032ee5c 15 bar(i); (gdb) display/i $pc 1: x/i $pc 0x32ee5c : P2=R7; (gdb) stepi 0x0032ee5e 15 bar(i); 1: x/i $pc 0x32ee5e : R1=[P2+0x44]; (gdb) stepi 0x0032ee62 15 bar(i); 1: x/i $pc 0x32ee62 : P2=R1; (gdb) stepi 0x0032ee64 15 bar(i); 1: x/i $pc 0x32ee64 : P1=[P2]; (gdb) stepi 0x0032ee66 15 bar(i); 1: x/i $pc 0x32ee66 : P3=[P2+0x4]; (gdb) stepi 0x0032ee68 15 bar(i); 1: x/i $pc 0x32ee68 : CALL (P1); (gdb) stepi 0xffa02214 in bar () 1: x/i $pc 0xffa02214 : NOP; (gdb) stepi 0xffa02218 in bar () 1: x/i $pc 0xffa02218 : NOP; (gdb) stepi 0xffa0221a in bar () 1: x/i $pc 0xffa0221a : NOP; (gdb) stepi 0xffa0221e in bar () 1: x/i $pc 0xffa0221e : NOP; (gdb) stepi 0xffa02220 in bar () 1: x/i $pc 0xffa02220 : NOP; (gdb) stepi 0xffa02224 in bar () 1: x/i $pc 0xffa02224 : NOP; (gdb) stepi 0xffa02226 in bar () 1: x/i $pc 0xffa02226 : NOP; (gdb) stepi 0xffa02228 in bar () 1: x/i $pc 0xffa02228 : NOP; (gdb) stepi 0xffa0222a in bar () 1: x/i $pc 0xffa0222a : NOP; (gdb) stepi First problem is that gdb thinks bar is at 0xffde7800, but it is really at 0xffa02214. -Robin