debugging something with multiple text sections in one compilation unit

[Robin Getz <rgetz@blackfin.uclinux.org>]

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