This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
debugging something with multiple text sections in one compilation unit
- From: Robin Getz <rgetz at blackfin dot uclinux dot org>
- To: gdb at sourceware dot org
- Date: Fri, 3 Aug 2007 00:09:46 -0400
- Subject: debugging something with multiple text sections in one compilation unit
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 <stdio.h>
#include <stdlib.h>
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 <main+28>: P2=R7;
(gdb) stepi
0x0032ee5e 15 bar(i);
1: x/i $pc 0x32ee5e <main+30>: R1=[P2+0x44];
(gdb) stepi
0x0032ee62 15 bar(i);
1: x/i $pc 0x32ee62 <main+34>: P2=R1;
(gdb) stepi
0x0032ee64 15 bar(i);
1: x/i $pc 0x32ee64 <main+36>: P1=[P2];
(gdb) stepi
0x0032ee66 15 bar(i);
1: x/i $pc 0x32ee66 <main+38>: P3=[P2+0x4];
(gdb) stepi
0x0032ee68 15 bar(i);
1: x/i $pc 0x32ee68 <main+40>: CALL (P1);
(gdb) stepi
0xffa02214 in bar ()
1: x/i $pc 0xffa02214 <bar>: NOP;
(gdb) stepi
0xffa02218 in bar ()
1: x/i $pc 0xffa02218 <bar+4>: NOP;
(gdb) stepi
0xffa0221a in bar ()
1: x/i $pc 0xffa0221a <bar+6>: NOP;
(gdb) stepi
0xffa0221e in bar ()
1: x/i $pc 0xffa0221e <bar+10>: NOP;
(gdb) stepi
0xffa02220 in bar ()
1: x/i $pc 0xffa02220 <bar+12>: NOP;
(gdb) stepi
0xffa02224 in bar ()
1: x/i $pc 0xffa02224 <bar+16>: NOP;
(gdb) stepi
0xffa02226 in bar ()
1: x/i $pc 0xffa02226 <bar+18>: NOP;
(gdb) stepi
0xffa02228 in bar ()
1: x/i $pc 0xffa02228 <bar+20>: NOP;
(gdb) stepi
0xffa0222a in bar ()
1: x/i $pc 0xffa0222a <bar+22>: NOP;
(gdb) stepi
First problem is that gdb thinks bar is at 0xffde7800, but it is really at
0xffa02214.
-Robin