dwarf2 and .gnu.linkonce sections

[Stanley Gambarin <stanleyg76 at yahoo dot com>]

Hello,

  i think that i've ran against a bug in the linker,
but would like a bit more information.  This is under
binutils 2.13.2 compiled for arm-elf target, running
on Solaris.

  i have a simple c++ app, 2 source files and one
common header file defining a class and providing 
its operators.  Compiling each .cpp file with
-gdwarf-2
and examining the produced debug output shows that
.debug_line section entries have been generated for
some function which reside in .gnu.linkonce.t....
sections (this happened for non-inlined operators).
During linking, .debug_line sections from 2 object 
files will be concatenated, while only one of the
.gnu.linkonce.t... sections will make it to the 
final executable.  Therefore, (as my arm-elf-readelf
shows), the relocations from .debug_line section in
the second object file will point to the "removed"
.gnu.linkonce.t... section.  Linker does not emit
any messages (that i can see), but just assumes 
base address of that section at 0 (and produces wrong
debug info).

Question:  should the .debug_line follow the path
of .debug_info sections ? i.e. should the compiler
generate .gnu.linkonce.wl.??? section that contains
debug line entries for a function located in 
.gnu.linkonce.t.??? section; should the linker at
least emit some warning messages about relocations
against removed section ? should the linker apply
relocations to the related section that was not 
removed (this assumes that section info is the same,
but i'm not sure if that is true)

any feeedback ??
-- stanley

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com