debugging something with multiple text sections in one compilation unit

debugging something with multiple text sections in one compilation unit

[Robin Getz]

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

Re: debugging something with multiple text sections in one compilation unit

[Daniel Jacobowitz]

On Fri, Aug 03, 2007 at 12:09:46AM -0400, Robin Getz wrote:
> 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.

There is no requirement to use a single base address in DWARF, or in
GDB's implementation of it; just use .debug_aranges.  GCC does the
right thing if you use __attribute__((section)).

You're supposed to tell GDB the section offsets, so that it can adjust
debug info appropriately.  See add-symbol-file in the manual.  There's
no way yet to do this automatically for a single section, though; only
by hand.

-- 
Daniel Jacobowitz
CodeSourcery

Re: debugging something with multiple text sections in onecompilation unit

[Robin Getz]

On Fri 3 Aug 2007 07:37, Daniel Jacobowitz pondered:
> On Fri, Aug 03, 2007 at 12:09:46AM -0400, Robin Getz wrote:
> > 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.
> 
> There is no requirement to use a single base address in DWARF, or in
> GDB's implementation of it; just use .debug_aranges.  GCC does the
> right thing if you use __attribute__((section)).

Thanks for the pointer - I will check to make sure the compiler is populating 
this properly (which it looks like it is).

I found this discussion (after I knew what to search for)
http://www.eagercon.com/dwarf/issues/001101-1.htm

> You're supposed to tell GDB the section offsets, so that it can adjust
> debug info appropriately.  See add-symbol-file in the manual.  There's
> no way yet to do this automatically for a single section, though; only
> by hand.

I assume it should be "add-symbol-file -file filename -sl1_text address"
Hmm... That stinks.

Since gdb knows there are multiple discontinuous sections (via 
parsing .debug_aranges) why not just ask the kernel where the section was 
loaded?

Or is it "it's possible, just not implemented"

-Robin

Re: debugging something with multiple text sections in onecompilation unit

[Daniel Jacobowitz]

On Fri, Aug 03, 2007 at 10:01:19AM -0400, Robin Getz wrote:
> Since gdb knows there are multiple discontinuous sections (via 
> parsing .debug_aranges) why not just ask the kernel where the section was 
> loaded?
> 
> Or is it "it's possible, just not implemented"

Sure.  Take a look at how qOffsets works.  qOffsets is not rich enough
to specify what you need; but assuming you use sensible ELF segments,
the new code in HEAD after 6.6 could be easily exteneded to take more
than just a text and data segment.  We just didn't, because we didn't
have any users for that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: debugging something with multiple text sections inonecompilation unit

[Robin Getz]

On Fri 3 Aug 2007 10:02, Daniel Jacobowitz pondered:
> Take a look at how qOffsets works. 

Will do - thanks

> qOffsets is not rich enough to specify what you need; but assuming you use
> sensible ELF segments, the new code in HEAD after 6.6 could be easily
> exteneded to take more than just a text and data segment.  We just didn't,
> because we didn't have any users for that.   

We do now. :) 

We will have a look, and send a patch if we can get the copyright assignment 
sorted with the FSF.

-Robin