Problems with startup code symbols (Copious warnings)

Problems with startup code symbols (Copious warnings)

[Steven Johnson]

Hi,

For ever and a day with GDB i've gotten the following warnings:

warning: (Internal error: pc 0x00 in read in psymtab, but not in symtab.)

I get it a lot.  I even patch GDB so it doesn't generate this warning,
its so annoying.

0x00 happens to be my programs entry point (its an embedded system). 
And is in Assembler code.

I've never liked patching GDB to get rid of this warning, so I invested
some time on it and I've just discovered 2 ways to make it go away:

1. If I compile my code with stabs+ debug info, I don't get the
warning.  I would prefer to use Dwarf-2 however, as it seems to be the
way of the future.

2. If I add:

.section .debug_info,"",@progbits as the first directive in my asm file,
the warning also goes away.  But so does the code when I view it under GDB.

Does anyone know any special incantation I need to make in my ASM file,
to get rid of the warning, but still retain the symbolic information so
I can see the code and symbols under GDB?

The file is a ".S" file, it is assembler but i build it with GCC.  The
CPU is a PowerPC, Motorola MPC862.

Thanks,
Steven J

Re: Problems with startup code symbols (Copious warnings)

[Jim Blandy]

Steven Johnson <sjohnson@sakuraindustries.com> writes:
> For ever and a day with GDB i've gotten the following warnings:
>
> warning: (Internal error: pc 0x00 in read in psymtab, but not in symtab.)
>
> I get it a lot.  I even patch GDB so it doesn't generate this warning,
> its so annoying.
>
> 0x00 happens to be my programs entry point (its an embedded system). 
> And is in Assembler code.
>
> I've never liked patching GDB to get rid of this warning, so I invested
> some time on it and I've just discovered 2 ways to make it go away:
>
> 1. If I compile my code with stabs+ debug info, I don't get the
> warning.  I would prefer to use Dwarf-2 however, as it seems to be the
> way of the future.
>
> 2. If I add:
>
> .section .debug_info,"",@progbits as the first directive in my asm file,
> the warning also goes away.  But so does the code when I view it under GDB.
>
> Does anyone know any special incantation I need to make in my ASM file,
> to get rid of the warning, but still retain the symbolic information so
> I can see the code and symbols under GDB?
>
> The file is a ".S" file, it is assembler but i build it with GCC.  The
> CPU is a PowerPC, Motorola MPC862.

Can you post an executable for which GDB produces this message, and
let us know which target you've configured GDB for?

Re: Problems with startup code symbols (Copious warnings)

[Steven Johnson]

Jim Blandy wrote:

>Steven Johnson <sjohnson@sakuraindustries.com> writes:
>  
>
>>For ever and a day with GDB i've gotten the following warnings:
>>
>>warning: (Internal error: pc 0x00 in read in psymtab, but not in symtab.)
>>
>>I get it a lot.  I even patch GDB so it doesn't generate this warning,
>>its so annoying.
>>
>>0x00 happens to be my programs entry point (its an embedded system). 
>>And is in Assembler code.
>>
>>I've never liked patching GDB to get rid of this warning, so I invested
>>some time on it and I've just discovered 2 ways to make it go away:
>>
>>1. If I compile my code with stabs+ debug info, I don't get the
>>warning.  I would prefer to use Dwarf-2 however, as it seems to be the
>>way of the future.
>>
>>2. If I add:
>>
>>.section .debug_info,"",@progbits as the first directive in my asm file,
>>the warning also goes away.  But so does the code when I view it under GDB.
>>
>>Does anyone know any special incantation I need to make in my ASM file,
>>to get rid of the warning, but still retain the symbolic information so
>>I can see the code and symbols under GDB?
>>
>>The file is a ".S" file, it is assembler but i build it with GCC.  The
>>CPU is a PowerPC, Motorola MPC862.
>>    
>>
>
>Can you post an executable for which GDB produces this message, and
>let us know which target you've configured GDB for?
>
>  
>
I can't post my app, because of a number of reasons.  I will try to
coble together one I can post, that limits itself to this problem.

GDB is configured for powerpc-eabi or powerpc-rtems (doesn't matter
which, I've used both with the same results). 

Will post an app tomorrow that does this, once I've made one.

Steven J

Re: Problems with startup code symbols (Copious warnings)

[Steven Johnson]

[-- Attachment #1: Type: text/plain, Size: 5649 bytes --]

Here is an example application which demonstrates the problem I experience.

test.elf = linked application for powerpc-eabi (rtems actually, but it
should make no difference).
test.link = link script used
test.map = map file generated by link
vectors.o = intermediary object of vectors.S
vectors.S = my test application which doesn't do much.

If I load this in GDB and try to debug i get the following errors,
repeatedly:

(Internal error: pc 0x0 in read in psymtab, but not in symtab.)
(Internal error: pc 0x100 in read in psymtab, but not in symtab.)

These are the commands I use to build it:

/opt/X-GCC/bin/powerpc-rtems-gcc -gdwarf-2 -nostdinc
-Wa,-mregnames,-mppc,-memb -w -Wall -Werror -msoft-float -mcpu=860 -O1
-foptimize-sibling-calls -mstring -mmultiple -funit-at-a-time
-ffunction-sections -fdata-sections -fcse-follow-jumps
-frerun-cse-after-loop -fcrossjumping -fdelete-null-pointer-checks
-fregmove -ftree-vrp -c -o vectors.o vectors.S -v
/opt/X-GCC/bin/powerpc-rtems-g++ -o test.elf -nodefaultlibs -static
-Wl,'--gc-sections' -Wl,'-nostdlib' -Wl,'-Map','test.map' -Wl,'--cref'
-Wl,'-dc' -Wl,'-dp' -Wl,'-u','__vectors' -Wl,'-N' -Wl,'-u','start'
-Wl,'-T','test.link' vectors.o -v

Here is the output from the build:

Using built-in specs.
Target: powerpc-rtems
Configured with: ../gcc-4.1.0/configure --host=i686-linux
--target=powerpc-rtems --prefix=/opt/X-GCC --enable-languages=c,c++
--with-newlib --disable-shared --enable-target-optspace --disable-libssp
--disable-nls --enable-version-specific-runtime-libs
--enable-threads=rtems --enable-newlib-multithread
--disable-newlib-supplied-syscalls --with-gnu-as --with-gnu-ld
Thread model: rtems
gcc version 4.1.0
 /opt/X-GCC/libexec/gcc/powerpc-rtems/4.1.0/cc1 -E -lang-asm -quiet
-nostdinc -v -Dmpc860 vectors.S -msoft-float -mcpu=860 -mstring
-mmultiple -Wall -Werror -w -foptimize-sibling-calls -funit-at-a-time
-ffunction-sections -fdata-sections -fcse-follow-jumps
-frerun-cse-after-loop -fcrossjumping -fdelete-null-pointer-checks
-fregmove -ftree-vrp -fworking-directory -O1 -o /home/linux/tmp/cceJbS47.s
#include "..." search starts here:
#include <...> search starts here:
End of search list.
 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/bin/as
--gdwarf2 -mppc -many -V -Qy -mregnames -mppc -memb -o vectors.o
/home/linux/tmp/cceJbS47.s
GNU assembler version 2.16.1 (powerpc-rtems) using BFD version 2.16.1
Using built-in specs.
Target: powerpc-rtems
Configured with: ../gcc-4.1.0/configure --host=i686-linux
--target=powerpc-rtems --prefix=/opt/X-GCC --enable-languages=c,c++
--with-newlib --disable-shared --enable-target-optspace --disable-libssp
--disable-nls --enable-version-specific-runtime-libs
--enable-threads=rtems --enable-newlib-multithread
--disable-newlib-supplied-syscalls --with-gnu-as --with-gnu-ld
Thread model: rtems
gcc version 4.1.0
 /opt/X-GCC/libexec/gcc/powerpc-rtems/4.1.0/collect2 -V -Qy -dn -Bstatic
-o test.elf
/opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
-L/opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0
-L/opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib
--gc-sections -nostdlib -Map test.map --cref -dc -dp -u __vectors -N -u
start -T test.link vectors.o
GNU ld version 2.16.1
  Supported emulations:
   elf32ppc

And finally GDB tells me the following if I start it with -v:

GNU gdb 6.4.0.20051202-cvs
Copyright 2005 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=powerpc-rtems".

Any help to resolve this warning would be greatly appreciated.

Steven J

Steven Johnson wrote:

>Jim Blandy wrote:
>
>  
>
>>Steven Johnson <sjohnson@sakuraindustries.com> writes:
>> 
>>
>>    
>>
>>>For ever and a day with GDB i've gotten the following warnings:
>>>
>>>warning: (Internal error: pc 0x00 in read in psymtab, but not in symtab.)
>>>
>>>I get it a lot.  I even patch GDB so it doesn't generate this warning,
>>>its so annoying.
>>>
>>>0x00 happens to be my programs entry point (its an embedded system). 
>>>And is in Assembler code.
>>>
>>>I've never liked patching GDB to get rid of this warning, so I invested
>>>some time on it and I've just discovered 2 ways to make it go away:
>>>
>>>1. If I compile my code with stabs+ debug info, I don't get the
>>>warning.  I would prefer to use Dwarf-2 however, as it seems to be the
>>>way of the future.
>>>
>>>2. If I add:
>>>
>>>.section .debug_info,"",@progbits as the first directive in my asm file,
>>>the warning also goes away.  But so does the code when I view it under GDB.
>>>
>>>Does anyone know any special incantation I need to make in my ASM file,
>>>to get rid of the warning, but still retain the symbolic information so
>>>I can see the code and symbols under GDB?
>>>
>>>The file is a ".S" file, it is assembler but i build it with GCC.  The
>>>CPU is a PowerPC, Motorola MPC862.
>>>   
>>>
>>>      
>>>
>>Can you post an executable for which GDB produces this message, and
>>let us know which target you've configured GDB for?
>>
>> 
>>
>>    
>>
>I can't post my app, because of a number of reasons.  I will try to
>coble together one I can post, that limits itself to this problem.
>
>GDB is configured for powerpc-eabi or powerpc-rtems (doesn't matter
>which, I've used both with the same results). 
>
>Will post an app tomorrow that does this, once I've made one.
>
>Steven J
>
>
>  
>


[-- Attachment #2: test.elf --]
[-- Type: application/octet-stream, Size: 19761 bytes --]

[-- Attachment #3: test.link --]
[-- Type: text/plain, Size: 4144 bytes --]


OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc",
              "elf32-powerpc")

OUTPUT_ARCH(powerpc);

ENTRY(BOOTSTRAP_ENTRY_FUNC);
EXTERN(BOOTSTRAP_ENTRY_FUNC);

MEMORY
{
  ram     (!rx) : org = 0x00000000, l = 16M
  stack   (!rx) : org = 0x01000000, l = 4
  dpram   (!rx) : org = 0xff000000, l = 16K
}

SECTIONS
{
  .text :
  {
    text.start = .;
    FILL(0xFFFF);
    vectors.start = .;

    *(.text.vectors)
    . = ALIGN(0x2000);
    vectors.end = .;

    *(.entry)
    *(.entry2)
    *(.rodata*)
    *(.eh_frame)
    *(.gnu.linkonce.r*)
    *(.rodata1)
    *(.gnu.linkonce.t.*)
    *(.descriptors)
    *(.gnu.warning)
    *(rom_ver)
    *(.text)
    *(.text*)

    . = ALIGN(0x10);
    _etext = .;

    __CTOR_LIST__ = .;
    LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
    KEEP(*(SORT(.ctors)))
    LONG(0)
    __CTOR_END__ = .;

    __DTOR_LIST__ = .;
    LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
    KEEP(*(SORT(.dtors)))
    LONG(0)
    __DTOR_END__ = .;

    *(.lit)
    *(.shdata)
    _init = .; KEEP(*(.init))
    _fini = .; KEEP(*(.fini))

    /*
     * Special FreeBSD sysctl sections.
     * Required for RTEMS BSD Network Stack.
     */
    . = ALIGN (16);
    __start_set_sysctl_set = .;
    *(set_sysctl_*);
    __stop_set_sysctl_set = ABSOLUTE(.);
    *(set_domain_*);
    *(set_pseudo_*);


    . = ALIGN(0x10);
    _endtest = .;
    text.end = .;
  } > ram

  /* R/W Data - Located in RAM Immediately after the program space. */
  .data :
  {
    FILL(0xFFFF);
    *(.data)
    *(.data*)
    *(.data1)
    *(.gnu.linkonce.d.*)
    PROVIDE (__SDATA_START__ = .);
    *(.sdata*)
    *(.gnu.linkonce.s.*)
  } > ram

  PROVIDE (__EXCEPT_START__ = .);
  .gcc_except_table :
  {
    *(.gcc_except_table)
  } > ram
  PROVIDE (__EXCEPT_END__ = .);

  __GOT_START__ = .;
  .got :
  {
    s.got = .;
    *(.got.plt)
    *(.got)
  } > ram
  __GOT_END__ = .;

  .got1 :
  {
    *(.got1)
  } > ram

  PROVIDE (__GOT2_START__ = .);
  PROVIDE (_GOT2_START_ = .);
  .got2 :
  {
    *(.got2)
  } > ram
  PROVIDE (__GOT2_END__ = .);
  PROVIDE (_GOT2_END_ = .);

  PROVIDE (__FIXUP_START__ = .);
  PROVIDE (_FIXUP_START_ = .);
  .fixup :
  {
    *(.fixup)
  } > ram
  PROVIDE (_FIXUP_END_ = .);
  PROVIDE (__FIXUP_END__ = .);

  PROVIDE (__SDATA2_START__ = .);
  .sdata2 :
  {
    *(.sdata2)
    *(.gnu.linkonce.s2.*)
  } > ram
  .sbss2 :
  {
    *(.sbss2)
    *(.gnu.linkonce.sb2.*)
  } > ram
  PROVIDE (__SBSS2_END__ = .);

  __SBSS_START__ = .;
  .bss :
  {
    bss.start = .;
    *(.bss)
    *(.bss.*)
    *(.sbss)
    *(.sbss.*)
    *(COMMON)
    . = ALIGN(4);
    bss.end = .;
  } > ram
  __SBSS_END__ = .;

  bss.size = bss.end - bss.start;
  text.size = text.end - text.start;
  PROVIDE(_end = bss.end);

  dpram :
  {
    m862   = . ;
    _m862  = . ;
    .     += (8 * 1024);
  } > dpram


  /* Stabs debugging sections.  */
  .stab 0 : { *(.stab) }
  .stabstr 0 : { *(.stabstr) }
  .stab.excl 0 : { *(.stab.excl) }
  .stab.exclstr 0 : { *(.stab.exclstr) }
  .stab.index 0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment 0 : { *(.comment) }

  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }

  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }

  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }

  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }

  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /* These must appear regardless of  .  */

}

[-- Attachment #4: test.map --]
[-- Type: text/plain, Size: 17220 bytes --]


Allocating common symbols
Common symbol       size              file

__SBSS2_END__       0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__DTOR_END__        0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT2_START__      0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__init              0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__EXCEPT_START__    0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__CTOR_LIST__       0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__EXCEPT_END__      0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__FIXUP_START__     0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__SBSS_END__        0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT_END__         0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT_START__       0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__CTOR_END__        0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__DTOR_LIST__       0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__SDATA2_START__    0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__fini              0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__FIXUP_END__       0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT2_END__        0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__SDATA_START__     0x4               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o

Memory Configuration

Name             Origin             Length             Attributes
ram              0x00000000         0x01000000         !xr
stack            0x01000000         0x00000004         !xr
dpram            0xff000000         0x00004000         !xr
*default*        0x00000000         0xffffffff

Linker script and memory map

LOAD /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o

.text           0x00000000     0x2010
                0x00000000                text.start = .
 FILL mask 0xffff
                0x00000000                vectors.start = .
 *(.text.vectors)
 .text.vectors  0x00000000      0x104 vectors.o
                0x00000100                RESET_ENTRY_FUNC
                0x00000000                BOOTSTRAP_ENTRY_FUNC
                0x00000000                vectors
                0x00002000                . = ALIGN (0x2000)
 *fill*         0x00000104     0x1efc ffff
                0x00002000                vectors.end = .
 *(.entry)
 *(.entry2)
 *(.rodata*)
 *(.eh_frame)
 *(.gnu.linkonce.r*)
 *(.rodata1)
 *(.gnu.linkonce.t.*)
 *(.descriptors)
 *(.gnu.warning)
 *(rom_ver)
 *(.text)
 *(.text*)
                0x00002000                . = ALIGN (0x10)
                0x00002000                _etext = .
                0x00002000                __CTOR_LIST__ = .
                0x00002000        0x4 LONG 0x0 (((__CTOR_END__ - __CTOR_LIST__) / 0x4) - 0x2)
 *(SORT(.ctors))
                0x00002004        0x4 LONG 0x0
                0x00002008                __CTOR_END__ = .
                0x00002008                __DTOR_LIST__ = .
                0x00002008        0x4 LONG 0x0 (((__DTOR_END__ - __DTOR_LIST__) / 0x4) - 0x2)
 *(SORT(.dtors))
                0x0000200c        0x4 LONG 0x0
                0x00002010                __DTOR_END__ = .
 *(.lit)
 *(.shdata)
                0x00002010                _init = .
 *(.init)
                0x00002010                _fini = .
 *(.fini)
                0x00002010                . = ALIGN (0x10)
                0x00002010                __start_set_sysctl_set = .
 *(set_sysctl_*)
                0x00002010                __stop_set_sysctl_set = <code 340> (.)
 *(set_domain_*)
 *(set_pseudo_*)
                0x00002010                . = ALIGN (0x10)
                0x00002010                _endtest = .
                0x00002010                text.end = .

.data           0x00002010        0x0
 FILL mask 0xffff
 *(.data)
 *(.data*)
 *(.data1)
 *(.gnu.linkonce.d.*)
                0x00002010                PROVIDE (__SDATA_START__, .)
 *(.sdata*)
 *(.gnu.linkonce.s.*)
                0x00002010                PROVIDE (__EXCEPT_START__, .)

.gcc_except_table
 *(.gcc_except_table)
                0x00002010                PROVIDE (__EXCEPT_END__, .)
                0x00002010                __GOT_START__ = .

.got            0x00002010        0x0
                0x00002010                s.got = .
 *(.got.plt)
 *(.got)
                0x00002010                __GOT_END__ = .

.got1
 *(.got1)
                0x00002010                PROVIDE (__GOT2_START__, .)
                0x00002010                PROVIDE (_GOT2_START_, .)

.got2
 *(.got2)
                0x00002010                PROVIDE (__GOT2_END__, .)
                0x00002010                PROVIDE (_GOT2_END_, .)
                0x00002010                PROVIDE (__FIXUP_START__, .)
                0x00002010                PROVIDE (_FIXUP_START_, .)

.fixup
 *(.fixup)
                0x00002010                PROVIDE (_FIXUP_END_, .)
                0x00002010                PROVIDE (__FIXUP_END__, .)
                0x00002010                PROVIDE (__SDATA2_START__, .)

.sdata2
 *(.sdata2)
 *(.gnu.linkonce.s2.*)

.sbss2
 *(.sbss2)
 *(.gnu.linkonce.sb2.*)
                0x00002010                PROVIDE (__SBSS2_END__, .)
                0x00002010                __SBSS_START__ = .

.bss            0x00002010       0x48
                0x00002010                bss.start = .
 *(.bss)
 *(.bss.*)
 *(.sbss)
 .sbss          0x00002010       0x48 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
                0x00002010                __SBSS2_END__
                0x00002018                __GOT2_START__
                0x0000201c                __init
                0x00002020                __EXCEPT_START__
                0x00002028                __EXCEPT_END__
                0x0000202c                __FIXUP_START__
                0x00002044                __SDATA2_START__
                0x00002048                __fini
                0x0000204c                __FIXUP_END__
                0x00002050                __GOT2_END__
                0x00002054                __SDATA_START__
 *(.sbss.*)
 *(COMMON)
                0x00002058                . = ALIGN (0x4)
                0x00002058                bss.end = .
                0x00002058                __SBSS_END__ = .
                0x00000048                bss.size = (bss.end - bss.start)
                0x00002010                text.size = (text.end - text.start)
                0x00002058                PROVIDE (_end, bss.end)

dpram           0xff000000     0x2000
                0xff000000                m862 = .
                0xff000000                _m862 = .
                0xff002000                . = (. + 0x2000)
 *fill*         0xff000000     0x2000 00

.stab
 *(.stab)

.stabstr
 *(.stabstr)

.stab.excl
 *(.stab.excl)

.stab.exclstr
 *(.stab.exclstr)

.stab.index
 *(.stab.index)

.stab.indexstr
 *(.stab.indexstr)

.comment        0x00000000       0x12
 *(.comment)
 .comment       0x00000000       0x12 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o

.debug
 *(.debug)

.line
 *(.line)

.debug_srcinfo
 *(.debug_srcinfo)

.debug_sfnames
 *(.debug_sfnames)

.debug_aranges  0x00000000       0x40
 *(.debug_aranges)
 .debug_aranges
                0x00000000       0x20 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
 .debug_aranges
                0x00000020       0x20 vectors.o

.debug_pubnames
                0x00000000      0x3f5
 *(.debug_pubnames)
 .debug_pubnames
                0x00000000      0x3f5 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o

.debug_info     0x00000000     0x1039
 *(.debug_info)
 .debug_info    0x00000000      0xfec /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
 .debug_info    0x00000fec       0x4d vectors.o

.debug_abbrev   0x00000000      0x1f6
 *(.debug_abbrev)
 .debug_abbrev  0x00000000      0x1e2 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
 .debug_abbrev  0x000001e2       0x14 vectors.o

.debug_line     0x00000000      0x15d
 *(.debug_line)
 .debug_line    0x00000000      0x122 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
 .debug_line    0x00000122       0x3b vectors.o

.debug_frame    0x00000000      0x260
 *(.debug_frame)
 .debug_frame   0x00000000      0x260 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o

.debug_str      0x00000000      0x79e
 *(.debug_str)
 .debug_str     0x00000000      0x79e /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
                                0x7fe (size before relaxing)

.debug_loc      0x00000000      0x10a
 *(.debug_loc)
 .debug_loc     0x00000000      0x10a /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o

.debug_macinfo
 *(.debug_macinfo)

.debug_weaknames
 *(.debug_weaknames)

.debug_funcnames
 *(.debug_funcnames)

.debug_typenames
 *(.debug_typenames)

.debug_varnames
 *(.debug_varnames)
LOAD vectors.o
OUTPUT(test.elf elf32-powerpc)

Cross Reference Table

Symbol                                            File
BOOTSTRAP_ENTRY_FUNC                              vectors.o
RESET_ENTRY_FUNC                                  vectors.o
_SDA2_BASE_                                       vectors.o
_SDA_BASE_                                        vectors.o
__CTOR_END__                                      /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__CTOR_LIST__                                     /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__DTOR_END__                                      /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__DTOR_LIST__                                     /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__EXCEPT_END__                                    /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__EXCEPT_START__                                  /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__FIXUP_END__                                     /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__FIXUP_START__                                   /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT2_END__                                      /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT2_START__                                    /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT_END__                                       /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__GOT_START__                                     /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__SBSS2_END__                                     /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__SBSS_END__                                      /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__SDATA2_START__                                  /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__SDATA_START__                                   /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__fini                                            /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
__init                                            /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_calloc_r                                         /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_close_r                                          /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_fcntl_r                                          /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_free_r                                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_fstat_r                                          /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_getpid_r                                         /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_kill_r                                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_link_r                                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_lseek_r                                          /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_malloc_r                                         /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_open_r                                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_read_r                                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_realloc_r                                        /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_stat_r                                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_times_r                                          /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_unlink_r                                         /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
_write_r                                          /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
abort                                             /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
free                                              /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
isatty                                            /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
malloc                                            /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
raise                                             /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
realloc                                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_getspecific                             /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_key_create                              /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_key_delete                              /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_mutex_init                              /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_mutex_lock                              /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_mutex_trylock                           /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_mutex_unlock                            /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_once                                    /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_recursive_mutex_init                    /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_recursive_mutex_lock                    /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_recursive_mutex_trylock                 /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_recursive_mutex_unlock                  /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_gxx_setspecific                             /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
rtems_provides_crt0                               /opt/X-GCC/lib/gcc/powerpc-rtems/4.1.0/../../../../powerpc-rtems/lib/crt0.o
vectors                                           vectors.o

[-- Attachment #5: vectors.o --]
[-- Type: application/octet-stream, Size: 1728 bytes --]

[-- Attachment #6: vectors.S --]
[-- Type: text/plain, Size: 1870 bytes --]

/********************************************************************
 *  Vector Table
 *  Execution Starts Here. Must be Linked to the appropriate Location.
 *  Startup is absolute address 0x00000000.
 ********************************************************************/
  .section  ".text"
  .section  .text.vectors,"ax",@progbits

.globl vectors         // Base Label of Vector Table.

/********************************************************************/
/*      .section   .vectors*/

/*****************************
 * Vector Table Offsets
 *****************************/
#define vector_base    0x00000000 // Physical Vector Table base Address
#define begin_vector   0x00000    // Vector Address where execution begins. (Not Reset).

/*****************************
 * Standard PowerPC Vectors
 *****************************/
#define vector_SYSTEM_RESET 0x00100 // System reset.

/************************************************************
 * STANDARD POWERPC VECTORS
 ************************************************************/
.org   vector_base
vectors:

/************************************************************
 * BOOTSTRAP_ENTRY
 *
 * MACRO, defines standard Entry Point to run once the
 * Program has been loaded by the Bootstrap.
 *
 ************************************************************/
  .org  begin_vector+vector_base
.globl BOOTSTRAP_ENTRY_FUNC
BOOTSTRAP_ENTRY_FUNC:
  .globl RESET_ENTRY_FUNC
  .type BOOTSTRAP_ENTRY_FUNC, @function
  b   RESET_ENTRY_FUNC
BOOTSTRAP_ENTRY_FUNC_END:

/************************************************************
 * RESET_ENTRY
 *
 * MACRO, defines standard Entry Point to run as a reset of
 * the application.
 *
 ************************************************************/
  .org  vector_SYSTEM_RESET+vector_base
.globl RESET_ENTRY_FUNC
RESET_ENTRY_FUNC:
  b   RESET_ENTRY_FUNC
RESET_ENTRY_FUNC_END:

Re: Problems with startup code symbols (Copious warnings)

[Jim Blandy]

Steven Johnson <sjohnson@sakuraindustries.com> writes:
> Will post an app tomorrow that does this, once I've made one.

I see your post in the archive, but for some reason it didn't reach
me.  I'll take a look.

Re: Problems with startup code symbols (Copious warnings)

[Jim Blandy]

Jim Blandy <jimb@codesourcery.com> writes:
> Steven Johnson <sjohnson@sakuraindustries.com> writes:
>> Will post an app tomorrow that does this, once I've made one.
>
> I see your post in the archive, but for some reason it didn't reach
> me.  I'll take a look.

Okay.  I think I understand part of the problem.

If you run 'readelf -wi' on your executable, you should see two
DW_TAG_compile_unit entries. Each has DW_AT_high_pc and DW_AT_low_pc
attributes.  The DWARF data claims that the crt0.c compilation unit
covers addresses zero to zero, and that the vectors.S compilation unit
covers addresses from zero to 0x104.

Then, each of them has a DW_AT_stmt_list that points to line number
information, which you can dump with 'readelf -wl'.  The crt0.c line
number info definitely seems to cover addresses outside the range
given in the crt0.c DW_TAG_compile_unit entry.  Which is odd.  Where
did the code from crt0.c really go? 

Is there some reason relocs against the debugging information aren't
getting applied?  I didn't quite get everything that was going on in
your link line.

The other part of the problem is that GDB distrusts DW_AT_low_pc
attributes whose values are zero, presuming that they refer to a
discarded 'linkonce' section.  Here's the code:

  /* When using the GNU linker, .gnu.linkonce. sections are used to
     eliminate duplicate copies of functions and vtables and such.
     The linker will arbitrarily choose one and discard the others.
     The AT_*_pc values for such functions refer to local labels in
     these sections.  If the section from that file was discarded, the
     labels are not in the output, so the relocs get a value of 0.
     If this is a discarded function, mark the pc bounds as invalid,
     so that GDB will ignore it.  */
  if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0)
    return 0;

(Linkonce sections are a crock: if a section of code is discarded, the
debug info should be discarded along with it, but there's no way to do
that with linkonce sections.)  But in your case, you really have a
compilation unit at address zero.

That crock is very important for debugging C++ code.  But I don't see
any way to distinguish between debug info for a discarded linkonce
section and debug info for a CU that is actually linked at address
zero.  They look the same.

But the effect is that GDB creates a symtab structure whose address
range is from zero to zero, built from a partial symtab whose address
range is from zero to 0x104, which is what produces the warnings: the
psymtab promises to cover a given range of code, but when it's
expanded into a full symtab, it doesn't.  It would be more consistent
for GDB to never construct the psymtab in the first place, on the
grounds that it looks like debug info for a discarded linkonce
section, but that wouldn't help you at all.

For now, I think a patch that uses complaints instead of warnings is
the best way to get GDB out of your hair.  But you're still going to
have problems.

If anyone can see a way to handle discarded linkonce sections better,
I'd love to hear it.

Re: Problems with startup code symbols (Copious warnings)

[Frederic RISS]

On Wed, 2006-06-14 at 17:12 -0700, Jim Blandy wrote:
[...]
>   /* When using the GNU linker, .gnu.linkonce. sections are used to
>      eliminate duplicate copies of functions and vtables and such.
>      The linker will arbitrarily choose one and discard the others.
>      The AT_*_pc values for such functions refer to local labels in
>      these sections.  If the section from that file was discarded, the
>      labels are not in the output, so the relocs get a value of 0.
>      If this is a discarded function, mark the pc bounds as invalid,
>      so that GDB will ignore it.  */
>   if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0)
>     return 0;
> 
> (Linkonce sections are a crock: if a section of code is discarded, the
> debug info should be discarded along with it, but there's no way to do
> that with linkonce sections.)  But in your case, you really have a
> compilation unit at address zero.
[...]
> If anyone can see a way to handle discarded linkonce sections better,
> I'd love to hear it.

What about looking at section VMAs? If one loadable section has a VMA of
0 then we can't discard debug info with low_pc == 0. If no section lives
at address 0 then low_pc == 0  implies that the relocations for this
info couldn't be applied because the code has vanished.
I'm sure I missed somethnig in the general case, but I've added
something like this as a post-load pass in a target_so_ops I implemented
some time ago and it worked well.

Fred.

Re: Problems with startup code symbols (Copious warnings)

[Steven Johnson]

Jim Blandy wrote:

>Jim Blandy <jimb@codesourcery.com> writes:
>  
>
>>Steven Johnson <sjohnson@sakuraindustries.com> writes:
>>    
>>
>>>Will post an app tomorrow that does this, once I've made one.
>>>      
>>>
>>I see your post in the archive, but for some reason it didn't reach
>>me.  I'll take a look.
>>    
>>
>
>Okay.  I think I understand part of the problem.
>
>If you run 'readelf -wi' on your executable, you should see two
>DW_TAG_compile_unit entries. Each has DW_AT_high_pc and DW_AT_low_pc
>attributes.  The DWARF data claims that the crt0.c compilation unit
>covers addresses zero to zero, and that the vectors.S compilation unit
>covers addresses from zero to 0x104.
>  
>
Well that was a problem.  crt0.c shouldn't have been there, I got rid of
it with -nostartfiles.  Now its not present in the readelf -wi, i only
have vectors.s covering the range 0-0x104.  It doesn't change the
problem, so its probably down to the link-once stuff below.

>Then, each of them has a DW_AT_stmt_list that points to line number
>information, which you can dump with 'readelf -wl'.  The crt0.c line
>number info definitely seems to cover addresses outside the range
>given in the crt0.c DW_TAG_compile_unit entry.  Which is odd.  Where
>did the code from crt0.c really go? 
>  
>
Don't know, it shouldn't have been there in the first place. I've never
noticed it before in debugging, because it seems only its debug info was
hanging around, no code from it seems to be in my projects???

>Is there some reason relocs against the debugging information aren't
>getting applied?  I didn't quite get everything that was going on in
>your link line.
>  
>
You have lost me here, I don't know what you mean?  Specifically, I
don't understand "relocs against the debugging information aren't
getting applied"?

>The other part of the problem is that GDB distrusts DW_AT_low_pc
>attributes whose values are zero, presuming that they refer to a
>discarded 'linkonce' section.  Here's the code:
>
>  /* When using the GNU linker, .gnu.linkonce. sections are used to
>     eliminate duplicate copies of functions and vtables and such.
>     The linker will arbitrarily choose one and discard the others.
>     The AT_*_pc values for such functions refer to local labels in
>     these sections.  If the section from that file was discarded, the
>     labels are not in the output, so the relocs get a value of 0.
>     If this is a discarded function, mark the pc bounds as invalid,
>     so that GDB will ignore it.  */
>  if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0)
>    return 0;
>  
>
This is without question what is breaking my debug session.  I commented
out this code and all works fine, and the error goes away.  I also
dumped the assumed discarded bfd information, to see if there was any
difference in my main project with the original code and any .linkonce
sections in it that could be identified, but it turns out I don't have
any .linkonce sections in my project.

I was about to suggest a flag that conditions off this test, instead of
the warning.  However I then received Freds post, and if that would
work, it would be better, cause it is automatic.  Unfortunately I am
quite lost here and wouldn't even know where to begin to check "If one
loadable section has a VMA of 0" otherwise I would throw a test together
to see if it fixed it.

Steven J

Re: Problems with startup code symbols (Copious warnings)

[Daniel Jacobowitz]

On Mon, Jun 19, 2006 at 10:15:56AM +0200, Frederic RISS wrote:
> What about looking at section VMAs? If one loadable section has a VMA of
> 0 then we can't discard debug info with low_pc == 0. If no section lives
> at address 0 then low_pc == 0  implies that the relocations for this
> info couldn't be applied because the code has vanished.
> I'm sure I missed somethnig in the general case, but I've added
> something like this as a post-load pass in a target_so_ops I implemented
> some time ago and it worked well.

The problem is that this only works for binaries which _either_ use
linkonce sections or code at zero.  A binary with both would still not
work very well.

Is that an improvement?  I guess so.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems with startup code symbols (Copious warnings)

[Frederic RISS]

On Tue, 2006-06-20 at 08:21 -0400, Daniel Jacobowitz wrote:
> On Mon, Jun 19, 2006 at 10:15:56AM +0200, Frederic RISS wrote:
> > What about looking at section VMAs? If one loadable section has a VMA of
> > 0 then we can't discard debug info with low_pc == 0. If no section lives
> > at address 0 then low_pc == 0  implies that the relocations for this
> > info couldn't be applied because the code has vanished.
> > I'm sure I missed somethnig in the general case, but I've added
> > something like this as a post-load pass in a target_so_ops I implemented
> > some time ago and it worked well.
> 
> The problem is that this only works for binaries which _either_ use
> linkonce sections or code at zero.  A binary with both would still not
> work very well.

Of course. But I don't see any non-embedded binary with a section loaded
at NULL. And I don't see much embedded bootcode needing linkonce
sections.

> Is that an improvement?  I guess so.

It's certainly better than the current HAS_RELOCS check.

Re: Problems with startup code symbols (Copious warnings)

[Daniel Jacobowitz]

On Tue, Jun 20, 2006 at 02:32:17PM +0200, Frederic RISS wrote:
> Of course. But I don't see any non-embedded binary with a section loaded
> at NULL.

Probably...

> And I don't see much embedded bootcode needing linkonce
> sections.

... but not probably.

Typical for a lot of embedded devices I've worked with is to have a
single massive ELF image, including boot code and the entire remainder
of the image, and to use C++ for most of it.  I've definitely worked
with images where this wouldn't help.

> > Is that an improvement?  I guess so.
> 
> It's certainly better than the current HAS_RELOCS check.

Yes, I think so.  Want to do it, anybody?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems with startup code symbols (Copious warnings)

[Frederic RISS]

On Tue, 2006-06-20 at 08:37 -0400, Daniel Jacobowitz wrote:
> > And I don't see much embedded bootcode needing linkonce
> > sections.
> 
> ... but not probably.
> 
> Typical for a lot of embedded devices I've worked with is to have a
> single massive ELF image, including boot code and the entire remainder
> of the image, and to use C++ for most of it.  I've definitely worked
> with images where this wouldn't help.

I said I must have missed something in my initial mail :-)

> > > Is that an improvement?  I guess so.
> > 
> > It's certainly better than the current HAS_RELOCS check.
> 
> Yes, I think so.  Want to do it, anybody?

I'll give it a try, if nobody beats me at it. I won't have any time in
the upcoming days though, so don't expect it too soon.

Re: Problems with startup code symbols (Copious warnings)

[Steven Johnson]

As I understand the approach suggested, there will be a scan through the
sections of the ELF (.text, .data, etc), looking for VMA's of zero.  If
there is one, the test isn't performed and the debug info isn't discard.

Is it possible to to tell what section the debug info is for?  If so,
could it only not discard the debug info if it is in the particular
section with the VMA of 0.

If this is possible, I think it would be better, because (at least in my
experience) when you are trying to control the link order of things, and
have your code which starts at zero always start there, its put into a
special section like, .boot or .vectors, or some such anyway.  That
would be the only section with a VMA of 0.  Other sections, like .text
wouldn't have a VMA of zero and debug info from them with a low_pc of 0
could surely be discarded.

Even if this requires a change for future embedded programs that are
effected by this to force them to have a unique section name for the
section which starts at zero and to ensure there are no features of the
language/link used which would put .linkonce sections in this "starting
at zero" section, this would, i think, be preferrable to the current
situation.

Steven J

Frederic RISS wrote:

>On Tue, 2006-06-20 at 08:37 -0400, Daniel Jacobowitz wrote:
>  
>
>>>And I don't see much embedded bootcode needing linkonce
>>>sections.
>>>      
>>>
>>... but not probably.
>>
>>Typical for a lot of embedded devices I've worked with is to have a
>>single massive ELF image, including boot code and the entire remainder
>>of the image, and to use C++ for most of it.  I've definitely worked
>>with images where this wouldn't help.
>>    
>>
>
>I said I must have missed something in my initial mail :-)
>
>  
>
>>>>Is that an improvement?  I guess so.
>>>>        
>>>>
>>>It's certainly better than the current HAS_RELOCS check.
>>>      
>>>
>>Yes, I think so.  Want to do it, anybody?
>>    
>>
>
>I'll give it a try, if nobody beats me at it. I won't have any time in
>the upcoming days though, so don't expect it too soon.
>
>
>  
>

Re: Problems with startup code symbols (Copious warnings)

[Daniel Jacobowitz]

On Wed, Jun 21, 2006 at 07:13:21AM +1100, Steven Johnson wrote:
> Is it possible to to tell what section the debug info is for?

No, at this point, that's exactly the problem.  The necessary
information is gone.

Long term, the correct fix to this is not in GDB anyway.  Both linker
and compiler fixes have been pursued.  Someone just needs to push
through on it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problems with startup code symbols (Copious warnings)

[Frederic RISS]

On Tue, 2006-06-20 at 19:34 -0400, Daniel Jacobowitz wrote:
> On Wed, Jun 21, 2006 at 07:13:21AM +1100, Steven Johnson wrote:
> > Is it possible to to tell what section the debug info is for?
> 
> No, at this point, that's exactly the problem.  The necessary
> information is gone.
> 
> Long term, the correct fix to this is not in GDB anyway.  Both linker
> and compiler fixes have been pursued.  Someone just needs to push
> through on it.

Just out of curiosity, do you have any pointers to these 'pursued
fixes'? 

Re: Problems with startup code symbols (Copious warnings)

[Steven Johnson]

Frederic RISS wrote:

>On Tue, 2006-06-20 at 19:34 -0400, Daniel Jacobowitz wrote:
>  
>
>>On Wed, Jun 21, 2006 at 07:13:21AM +1100, Steven Johnson wrote:
>>    
>>
>>>Is it possible to to tell what section the debug info is for?
>>>      
>>>
>>No, at this point, that's exactly the problem.  The necessary
>>information is gone.
>>
>>    
>>
Ok, from my poking around it seemed that what was still known however
was the file name the symbol comes from (correct?).  Again, it would
seem unlikely that code from a file starting at 0, would also contain
code trigerring link once behaviour.  So, what about (until a better fix
comes along) a settable variable that is the name of a file to ignore
the "discard symbols for link once sections" behaviour?

Something like:

set this-file-validly-starts-at-zero vectors.S

As we are talking about a single problematic address, a single option
should be all that's required, as 2 files can't both start at the same
address (assuming no one has overlays going on at address 0).

If this is acceptable, id like it if anyone can propose a more suitable
name for the option as I'm stumped for a decent one.

This is something I AM comfortable in adding to GDB, Docs, etc.  And
will happilly do it by this weekend, if its OK with everyone concerned.

>>Long term, the correct fix to this is not in GDB anyway.  Both linker
>>and compiler fixes have been pursued.  Someone just needs to push
>>through on it.
>>    
>>
>
>Just out of curiosity, do you have any pointers to these 'pursued
>fixes'? 
>  
>
I too would be interested in pointers to this.

Steven J

Re: Problems with startup code symbols (Copious warnings)

[Daniel Jacobowitz]

On Wed, Jun 21, 2006 at 10:10:29AM +0200, Frederic RISS wrote:
> On Tue, 2006-06-20 at 19:34 -0400, Daniel Jacobowitz wrote:
> > On Wed, Jun 21, 2006 at 07:13:21AM +1100, Steven Johnson wrote:
> > > Is it possible to to tell what section the debug info is for?
> > 
> > No, at this point, that's exactly the problem.  The necessary
> > information is gone.
> > 
> > Long term, the correct fix to this is not in GDB anyway.  Both linker
> > and compiler fixes have been pursued.  Someone just needs to push
> > through on it.
> 
> Just out of curiosity, do you have any pointers to these 'pursued
> fixes'? 

1.  Alan Modra posted an initial implementation of linker support for
debug info editing.  The linker would simply discard extra DIEs.  But,
it wasn't complete.  This was maybe two months ago.

2.  The generally accepted Right Fix is to use ELF COMDAT groups
instead of linkonce sections, and then whenever the compiler discards a
section, it can discard the whole group including its DIEs.

-- 
Daniel Jacobowitz
CodeSourcery