Wrong address for static function in linux module

Wrong address for static function in linux module

[Jean-Rene Peulve]

Hi,
I am debugging a linux module on a Coldfire and I encounter the following
problem:
  -functions which have the static attribut are always relocated at offset 0
   of the .text section with the break command when the display command at the
   right address disassemble the right static function.
  -functions without the static attribut are relocated properly.

  I found out that the psymtab entry for a static function is relocated at the
  right offset in the .text section when the symtab entry for the same function
  is relocated at offset 0 of the .text section.

  To generate the target software, I use gcc 2.95.3
  I was using gdb 5.2.1, then I fetch gdb-6.4.50.20060405 and get the same
  problem.

Here are the details:

The nm command gives:
   - 00000136 t horloge_read
   - 0000037a T HorlogeCheck

I put a breakpoint at exit of the lookup_symbol to display the content of the
struct symbol (here this is gdb-6.4.50.20060405):

(top-gdb) b lookup_symbol
During symbol reading, inner block (0x770-0x83d) not inside outer block 
(0x80a309
c-0x80a31a4).
During symbol reading, block at 0x776 out of order.
Breakpoint 3 at 0x80a378d: file ../../gdb-6.4.50.20060405/gdb/symtab.c, 
line 1028
.
(top-gdb) c
Continuing.

Breakpoint 3, lookup_symbol (name=0x832d180 "HorlogeCheck", block=0x0,
     domain=VAR_DOMAIN, is_a_field_of_this=0x0, symtab=0x0)
     at ../../gdb-6.4.50.20060405/gdb/symtab.c:1028
1028      if (current_language->la_language == language_cplus)
(top-gdb) fin
Run till exit from #0  lookup_symbol (name=0x832d180 "HorlogeCheck", 
block=0x0,
     domain=VAR_DOMAIN, is_a_field_of_this=0x0, symtab=0x0)
     at ../../gdb-6.4.50.20060405/gdb/symtab.c:1028
c_lex () at c-exp.y:1740
1740        if (sym && SYMBOL_CLASS (sym) == LOC_BLOCK)
Value returned is $1 = (struct symbol *) 0x83f1ab0
(top-gdb) p *(struct symbol *) 0x83f1ab0
$2 = {ginfo = {name = 0x8381388 "HorlogeCheck", value = {ivalue = 138353432,
       block = 0x83f1b18, bytes = 0x83f1b18 "Ú\003y", address = 138353432,
       chain = 0x83f1b18}, language_specific = {cplus_specific = {
         demangled_name = 0x0}}, language = language_c, section = 0,
     bfd_section = 0x837da44}, type = 0x83f1ad8, domain = VAR_DOMAIN,
   aclass = LOC_BLOCK, line = 627, ops = 0x0, aux_value = {basereg = 0,
     ptr = 0x0}, hash_next = 0x0}
(top-gdb) x/x ((struct symbol *) 0x83f1ab0)->ginfo.value.ivalue
0x83f1b18:      0x007903da  <<<=== offset 0x37a of .text OK
(top-gdb) c
Continuing.

Breakpoint 3, lookup_symbol (name=0x832d180 "horloge_read", block=0x0,
     domain=VAR_DOMAIN, is_a_field_of_this=0x0, symtab=0x0)
     at ../../gdb-6.4.50.20060405/gdb/symtab.c:1028
1028      if (current_language->la_language == language_cplus)
(top-gdb) fin
Run till exit from #0  lookup_symbol (name=0x832d180 "horloge_read", 
block=0x0,
     domain=VAR_DOMAIN, is_a_field_of_this=0x0, symtab=0x0)
     at ../../gdb-6.4.50.20060405/gdb/symtab.c:1028
c_lex () at c-exp.y:1740
1740        if (sym && SYMBOL_CLASS (sym) == LOC_BLOCK)
Value returned is $3 = (struct symbol *) 0x83e6e3c
(top-gdb) p *(struct symbol *) 0x83e6e3c
$4 = {ginfo = {name = 0x8381284 "horloge_read", value = {ivalue = 138309632,
       block = 0x83e7000, bytes = 0x83e7000 "`", address = 138309632,
       chain = 0x83e7000}, language_specific = {cplus_specific = {
         demangled_name = 0x0}}, language = language_c, section = 0,
     bfd_section = 0x837da44}, type = 0x83e6e64, domain = VAR_DOMAIN,
   aclass = LOC_BLOCK, line = 375, ops = 0x0, aux_value = {basereg = 0,
     ptr = 0x0}, hash_next = 0x0}
(top-gdb) x/x ((struct symbol *) 0x83e6e3c)->ginfo.value.ivalue
0x83e7000:      0x00790060       <<<=== offset 0 of .text BAD BAD
(top-gdb)
I tried to go further to debug this problem but without succes so far.

Any help would be  appreciated.

Jean-Rene Peulve

Re: Wrong address for static function in linux module

[Daniel Jacobowitz]

On Tue, Apr 11, 2006 at 11:01:13AM +0200, Jean-Rene Peulve wrote:
> Hi,
> I am debugging a linux module on a Coldfire and I encounter the following
> problem:
>  -functions which have the static attribut are always relocated at offset 0
>   of the .text section with the break command when the display command at 
>   the
>   right address disassemble the right static function.
>  -functions without the static attribut are relocated properly.
> 
>  I found out that the psymtab entry for a static function is relocated at 
>  the
>  right offset in the .text section when the symtab entry for the same 
>  function
>  is relocated at offset 0 of the .text section.
> 
>  To generate the target software, I use gcc 2.95.3
>  I was using gdb 5.2.1, then I fetch gdb-6.4.50.20060405 and get the same
>  problem.

This is normally supposed to be handled in
symfile_relocate_debug_section.  Are the bad functions really in
".text", or in another named text section?  Does the debug section
have proper relocations for that .debug_info entry (readelf -r)?


-- 
Daniel Jacobowitz
CodeSourcery

Re: Wrong address for static function in linux module

[Jean-Rene Peulve]

Hi Daniel,
See below.
Jean-Rene Peulvé
At 15:11 11/04/06, Daniel Jacobowitz wrote:
>On Tue, Apr 11, 2006 at 11:01:13AM +0200, Jean-Rene Peulve wrote:
> > Hi,
> > I am debugging a linux module on a Coldfire and I encounter the following
> > problem:
> >  -functions which have the static attribut are always relocated at offset 0
> >   of the .text section with the break command when the display command at
> >   the
> >   right address disassemble the right static function.
>
>This is normally supposed to be handled in
>symfile_relocate_debug_section.  Are the bad functions really in
>".text", or in another named text section?
Both functions horloge_read and HorlogeCheck are in the .text section.

>   Does the debug section
>have proper relocations for that .debug_info entry (readelf -r)?

Here the output of m68k-elf-readelf -s horloge.o (using binutils-2.16.1):
I am not familiar with the following output. static functions does not show
up in this list.

Relocation section '.rela.text' at offset 0x20060 contains 59 entries:
  Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000006  00000401 R_68K_32          00000000   .bss + 8
0000000c  00001e01 R_68K_32          00000000   jiffies + 0
00000012  00000301 R_68K_32          00000000   .data + 14
0000001a  00000201 R_68K_32          00000000   .text + 32
00000020  00000401 R_68K_32          00000000   .bss + 10
0000002a  00001f01 R_68K_32          00000000   add_timer + 0
00000038  00000301 R_68K_32          00000000   .data + 18
0000003e  00000301 R_68K_32          00000000   .data + 18
0000005c  00001c01 R_68K_32          00000008   horlogeWq + 0
00000062  00002001 R_68K_32          00000000   __wake_up + 0
00000068  00000201 R_68K_32          00000000   .text + 0
0000007e  00002101 R_68K_32          00000000   kmalloc + 0
00000096  00000301 R_68K_32          00000000   .data + 18
0000009c  00000301 R_68K_32          00000000   .data + 18
000000a4  00000301 R_68K_32          00000000   .data + 18
000000b0  00000301 R_68K_32          00000000   .data + 18
000000ba  00000301 R_68K_32          00000000   .data + 18
000000c4  00000301 R_68K_32          00000000   .data + 14
000000f2  00002201 R_68K_32          00000000   kfree + 0
000000f8  00000301 R_68K_32          00000000   .data + 18
00000100  00000301 R_68K_32          00000000   .data + 18
00000110  00000301 R_68K_32          00000000   .data + 18
00000116  00000301 R_68K_32          00000000   .data + 18
0000011e  00000401 R_68K_32          00000000   .bss + 0
00000124  00002301 R_68K_32          00000000   del_timer + 0
0000014c  00001c01 R_68K_32          00000008   horlogeWq + 0
00000152  00002401 R_68K_32          00000000   interruptible_sleep_on + 0
00000188  00001c01 R_68K_32          00000008   horlogeWq + 0
0000019c  00002501 R_68K_32          00000000   __pollwait + 0
000001c6  00000301 R_68K_32          00000000   .data + 14
000001f2  00002601 R_68K_32          00000000   _ramend + 0
000001fc  00002701 R_68K_32          00000000   is_in_rom + 0
0000020a  00002701 R_68K_32          00000000   is_in_rom + 0
00000224  00000501 R_68K_32          00000000   .rodata + 5
0000022a  00002801 R_68K_32          00000000   printk + 0
0000023e  00002601 R_68K_32          00000000   _ramend + 0
00000248  00002701 R_68K_32          00000000   is_in_rom + 0
00000256  00002701 R_68K_32          00000000   is_in_rom + 0
00000270  00000501 R_68K_32          00000000   .rodata + 2b
00000276  00002801 R_68K_32          00000000   printk + 0
000002a0  00002901 R_68K_32          00000000   memcpy + 0
000002bc  00000501 R_68K_32          00000000   .rodata + 52
000002c2  00002801 R_68K_32          00000000   printk + 0
000002d6  00000301 R_68K_32          00000000   .data + 14
000002e8  00000301 R_68K_32          00000000   .data + 14
000002fc  00002901 R_68K_32          00000000   memcpy + 0
00000306  00000301 R_68K_32          00000000   .data + 14
0000030e  00000401 R_68K_32          00000000   .bss + 0
00000314  00002301 R_68K_32          00000000   del_timer + 0
0000031a  00000201 R_68K_32          00000000   .text + 0
00000330  00000301 R_68K_32          00000000   .data + 20
00000336  00000501 R_68K_32          00000000   .rodata + 66
00000340  00002a01 R_68K_32          00000000   register_chrdev + 0
00000346  00000401 R_68K_32          00000000   .bss + 4
0000034c  00000401 R_68K_32          00000000   .bss + 0
0000035c  00000501 R_68K_32          00000000   .rodata + 66
00000366  00002b01 R_68K_32          00000000   unregister_chrdev + 0
0000036c  00000401 R_68K_32          00000000   .bss + 0
00000372  00002301 R_68K_32          00000000   del_timer + 0

Relocation section '.rela.data' at offset 0x20324 contains 10 entries:
  Offset     Info    Type            Sym.Value  Sym. Name + Addend
0000000c  00001c01 R_68K_32          00000008   horlogeWq + 4
00000010  00001c01 R_68K_32          00000008   horlogeWq + 4
00000018  00000301 R_68K_32          00000000   .data + 18
0000001c  00000301 R_68K_32          00000000   .data + 18
00000020  00001d01 R_68K_32          00000000   __this_module + 0
00000028  00000201 R_68K_32          00000000   .text + 136
00000034  00000201 R_68K_32          00000000   .text + 174
00000038  00000201 R_68K_32          00000000   .text + 1b4
00000040  00000201 R_68K_32          00000000   .text + 70
00000048  00000201 R_68K_32          00000000   .text + ce

Relocation section '.rela.stab' at offset 0x2039c contains 41 entries:
  Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000014  00000201 R_68K_32          00000000   .text + 0
00000020  00000201 R_68K_32          00000000   .text + 0
00002b40  00000601 R_68K_32          00000000   .modinfo + 0
00002c48  00000601 R_68K_32          00000000   .modinfo + 78
00002c60  00000301 R_68K_32          00000000   .data + 14
00002c6c  00000301 R_68K_32          00000000   .data + 18
00002c78  00000301 R_68K_32          00000000   .data + 20
00002c84  00000201 R_68K_32          00000000   .text + 0
00002cd8  00000201 R_68K_32          00000000   .text + 32
00002d14  00000201 R_68K_32          00000000   .text + 3c
00002d2c  00000201 R_68K_32          00000000   .text + 3c
00002d74  00000201 R_68K_32          00000000   .text + 4e
00002d8c  00000201 R_68K_32          00000000   .text + 4e
00002e40  00000201 R_68K_32          00000000   .text + 70
00002eac  00000201 R_68K_32          00000000   .text + 94
00002f48  00000201 R_68K_32          00000000   .text + be
00003044  00000201 R_68K_32          00000000   .text + ce
0000308c  00000201 R_68K_32          00000000   .text + de
000030ec  00000201 R_68K_32          00000000   .text + ea
0000311c  00000201 R_68K_32          00000000   .text + fc
00003134  00000201 R_68K_32          00000000   .text + fe
00003158  00000201 R_68K_32          00000000   .text + 10a
00003170  00000201 R_68K_32          00000000   .text + 10a
00003188  00000201 R_68K_32          00000000   .text + 10e
000031ac  00000201 R_68K_32          00000000   .text + 10e
000032e4  00000201 R_68K_32          00000000   .text + 136
000033f8  00000201 R_68K_32          00000000   .text + 174
00003434  00000201 R_68K_32          00000000   .text + 186
0000347c  00000201 R_68K_32          00000000   .text + 1a0
00003524  00000201 R_68K_32          00000000   .text + 1b4
000035b4  00000201 R_68K_32          00000000   .text + 1ea
00003620  00000201 R_68K_32          00000000   .text + 21e
0000365c  00000201 R_68K_32          00000000   .text + 236
000036c8  00000201 R_68K_32          00000000   .text + 26a
00003968  00000201 R_68K_32          00000000   .text + 32a
00003998  00000201 R_68K_32          00000000   .text + 344
000039c8  00000201 R_68K_32          00000000   .text + 350
00003a28  00000201 R_68K_32          00000000   .text + 356
00003a94  00002e01 R_68K_32          0000037a   HorlogeCheck + 0
00003ac4  00000401 R_68K_32          00000000   .bss + 0
00003ad0  00000201 R_68K_32          00000000   .text + 382

Output of m68k-elf-readelf -s horloge.o:
Symbol table '.symtab' contains 47 entries:
..
  12: 00000136    62 FUNC    LOCAL  DEFAULT    1 horloge_read
..
  46: 0000037a     8 FUNC    GLOBAL DEFAULT    1 HorlogeCheck


More details from maint print commands.

from the output of maint print symbols symbols.txt

    int horloge_read(struct file *, char *, size_t, loff_t *); block object
0x83a54f0, 0x790060..0x79009e section .text

     block #006, object at 0x83a54f0 under 0x83bdc54, 8 syms/buckets in
0x790060..0x79009e, function horloge_read, compiled with gcc2

from the output of maint print psymbols psymbols.txt
        `horloge_read', function, 0x790196

from the output of maint print msymbols msymbols.txt
    [ 9] t 0x790196 horloge_read section .text


gdb302bdi> x/i 0x791196
0x791196 <horloge_read at horloge.c:503>:       linkw %fp,#0

   Remark: the line number 503 is wrong as well !

gdb302bdi> x/i horloge_read
0x791060 <exit_horloge at horloge.c:589>:       linkw %fp,#0



>--
>Daniel Jacobowitz
>CodeSourcery

Re: Wrong address for static function in linux module

[Daniel Jacobowitz]

On Tue, Apr 11, 2006 at 03:33:32PM +0200, Jean-Rene Peulve wrote:
> Relocation section '.rela.stab' at offset 0x2039c contains 41 entries:
>  Offset     Info    Type            Sym.Value  Sym. Name + Addend

...

> 000032e4  00000201 R_68K_32          00000000   .text + 136

> Output of m68k-elf-readelf -s horloge.o:
> Symbol table '.symtab' contains 47 entries:
> ..
>  12: 00000136    62 FUNC    LOCAL  DEFAULT    1 horloge_read

There's your relocation of debug info.

It is entirely likely that the problem only happens because you're
using stabs.  It's supposed to work, but I've never tried it.  Try
taking a look at the contents of the .stab section at that offset
(0x32e4) in the file.  Then breakpoint after the call to
symfile_relocate_debug_section in elfstab_build_psymtabs, and see
what's at offset 0x32e4 now.  It should be a bit relocated.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Wrong address for static function in linux module

[Jean-Rene Peulve]

Hi Daniel,

At 15:38 11/04/06, Daniel Jacobowitz wrote:
>On Tue, Apr 11, 2006 at 03:33:32PM +0200, Jean-Rene Peulve wrote:
> > Relocation section '.rela.stab' at offset 0x2039c contains 41 entries:
> >  Offset     Info    Type            Sym.Value  Sym. Name + Addend
>
>...
>
> > 000032e4  00000201 R_68K_32          00000000   .text + 136
>
> > Output of m68k-elf-readelf -s horloge.o:
> > Symbol table '.symtab' contains 47 entries:
> > ..
> >  12: 00000136    62 FUNC    LOCAL  DEFAULT    1 horloge_read
>
>There's your relocation of debug info.
>
>It is entirely likely that the problem only happens because you're
>using stabs.  It's supposed to work, but I've never tried it.  Try
>taking a look at the contents of the .stab section at that offset
>(0x32e4) in the file.  Then breakpoint after the call to
>symfile_relocate_debug_section in elfstab_build_psymtabs, and see
>what's at offset 0x32e4 now.  It should be a bit relocated.

In bfd_perform_relocation for the .stab section I see that at line 633
relocation is 0 for the static function horloge_read when it is 0x37a for
the non static function HorlogeCheck.
I guess that the .stab section is wrong for static function as seen in
the readelf -r output. Only the non static have values != 0.

What do you recommend to use rather than stabs ?
Jean-René




>--
>Daniel Jacobowitz
>CodeSourcery

Re: Wrong address for static function in linux module

[Daniel Jacobowitz]

On Tue, Apr 11, 2006 at 04:31:32PM +0200, Jean-Rene Peulve wrote:
> Hi Daniel,
> 
> At 15:38 11/04/06, Daniel Jacobowitz wrote:
> >On Tue, Apr 11, 2006 at 03:33:32PM +0200, Jean-Rene Peulve wrote:
> >> Relocation section '.rela.stab' at offset 0x2039c contains 41 entries:
> >>  Offset     Info    Type            Sym.Value  Sym. Name + Addend
> >
> >...
> >
> >> 000032e4  00000201 R_68K_32          00000000   .text + 136
> >
> >> Output of m68k-elf-readelf -s horloge.o:
> >> Symbol table '.symtab' contains 47 entries:
> >> ..
> >>  12: 00000136    62 FUNC    LOCAL  DEFAULT    1 horloge_read
> >
> >There's your relocation of debug info.
> >
> >It is entirely likely that the problem only happens because you're
> >using stabs.  It's supposed to work, but I've never tried it.  Try
> >taking a look at the contents of the .stab section at that offset
> >(0x32e4) in the file.  Then breakpoint after the call to
> >symfile_relocate_debug_section in elfstab_build_psymtabs, and see
> >what's at offset 0x32e4 now.  It should be a bit relocated.
> 
> In bfd_perform_relocation for the .stab section I see that at line 633
> relocation is 0 for the static function horloge_read when it is 0x37a for
> the non static function HorlogeCheck.

That is not a problem.  That's just the symbol value, relative to the
start of .text.  Look down at line 645, and you'll see the addend
applied.

> What do you recommend to use rather than stabs ?

DWARF-2.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Wrong address for static function in linux module

[Jean-Rene Peulve]

Hi Daniel,

I was using -g  from the standard uClinux tree to build the kernel.

I just tried -gdwarf-2 and it seems to work.

I got it right with -ggdb as well.

Many thanks.

By the way I had to fixe
Jean-René
At 16:40 11/04/06, Daniel Jacobowitz wrote:
>On Tue, Apr 11, 2006 at 04:31:32PM +0200, Jean-Rene Peulve wrote:
> > Hi Daniel,
> >
> > At 15:38 11/04/06, Daniel Jacobowitz wrote:
> > >On Tue, Apr 11, 2006 at 03:33:32PM +0200, Jean-Rene Peulve wrote:
> > >> Relocation section '.rela.stab' at offset 0x2039c contains 41 entries:
> > >>  Offset     Info    Type            Sym.Value  Sym. Name + Addend
> > >
> > >...
> > >
> > >> 000032e4  00000201 R_68K_32          00000000   .text + 136
> > >
> > >> Output of m68k-elf-readelf -s horloge.o:
> > >> Symbol table '.symtab' contains 47 entries:
> > >> ..
> > >>  12: 00000136    62 FUNC    LOCAL  DEFAULT    1 horloge_read
> > >
> > >There's your relocation of debug info.
> > >
> > >It is entirely likely that the problem only happens because you're
> > >using stabs.  It's supposed to work, but I've never tried it.  Try
> > >taking a look at the contents of the .stab section at that offset
> > >(0x32e4) in the file.  Then breakpoint after the call to
> > >symfile_relocate_debug_section in elfstab_build_psymtabs, and see
> > >what's at offset 0x32e4 now.  It should be a bit relocated.
> >
> > In bfd_perform_relocation for the .stab section I see that at line 633
> > relocation is 0 for the static function horloge_read when it is 0x37a for
> > the non static function HorlogeCheck.
>
>That is not a problem.  That's just the symbol value, relative to the
>start of .text.  Look down at line 645, and you'll see the addend
>applied.
>
> > What do you recommend to use rather than stabs ?
>
>DWARF-2.
>
>--
>Daniel Jacobowitz
>CodeSourcery

stabs vs dwarf (was: Re: Wrong address for static function in linux module )

[David Taylor]

> Date: Tue, 11 Apr 2006 10:40:02 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Tue, Apr 11, 2006 at 04:31:32PM +0200, Jean-Rene Peulve wrote:
> 
> > What do you recommend to use rather than stabs ?
> 
> DWARF-2.

DWARF might be better for some things, but compactness is not one of
them.

Until dwarf gets smaller or some other compelling reason arises, I
suspect that many people will stay with STABS.  DWARF is very
voluminous by comparison to STABS.

I recently did builds of our software 3 ways --

    . stabs
    . dwarf-2
    . dwarf-2 with dup elimination

Ignoring the debug information, the executable files were identical
(of course).  And the ``dwarf-2 with dup elimination'' ones were
typically 20-30 percent smaller than the dwarf-2 ones built without
specifying -feliminate-dwarf2-dups.  But, the sizes of the ``dwarf-2
with dup elimination'' executable files was 1.7 to 9.2 times the
sizes of the corresponding stabs executable files.

A full build tree (build products only, no sources) is 8.7 GB with
STABS, but 24.6 GB when built with -gdwarf-2 -feliminate-dwarf2-dups.

David
--
David Taylor
dtaylor@emc.com

Re: stabs vs dwarf (was: Re: Wrong address for static function in linux module )

[Mark Kettenis]

> Date: Wed, 12 Apr 2006 11:38:09 -0400
> From: David Taylor <dtaylor@emc.com>
> 
> A full build tree (build products only, no sources) is 8.7 GB with
> STABS, but 24.6 GB when built with -gdwarf-2 -feliminate-dwarf2-dups.

You know if you compiled without debug information, your build tree
would be even smaller.  What matters is whether the debug info is
actually usable.  For unoptimized C code, stabs is probably fine.  But
for heavily optimized C++ code, it will be unusable.

Mark

Re: stabs vs dwarf (was: Re: Wrong address for static function in linux module )

[Eli Zaretskii]

> Date: Wed, 12 Apr 2006 20:24:56 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: drow@false.org, jr.peulve@wanadoo.fr, gdb@sources.redhat.com
> 
> > Date: Wed, 12 Apr 2006 11:38:09 -0400
> > From: David Taylor <dtaylor@emc.com>
> > 
> > A full build tree (build products only, no sources) is 8.7 GB with
> > STABS, but 24.6 GB when built with -gdwarf-2 -feliminate-dwarf2-dups.
> 
> You know if you compiled without debug information, your build tree
> would be even smaller.  What matters is whether the debug info is
> actually usable.  For unoptimized C code, stabs is probably fine.  But
> for heavily optimized C++ code, it will be unusable.

On the other hand, if the ``usable'' debug info uses up space that is
comparable to what the sources use up, we might as well ditch the
debug info, and instead implement an option in GCC that would use it
as an agent for telling GDB what it needs to know, and _only_ what it
needs to know.  That is, GDB would invoke GCC and ask it to provide
the info about some variable or function, and GCC will glean that from
the sources.

This is only a half-serious suggestion, the point being that a debug
info that is not optimized for debugger's usability in terms of memory
footprint and on-demand loading, is not very ``usable'', IMHO.