Re: dwarf2 and .gnu.linkonce sections

[Nick Clifton <nickc at redhat dot com>]

Hi Stanley,

>   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).

This is definitely a bug then.  Either the unresolvable debug entries
should be removed, or the linker should produce a warning.

> 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;

Actually this sounds like a very good idea.  Maybe you could suggest
it on the gcc mailing list as well ?

> should the linker at least emit some warning messages about
> relocations against removed section ?

If it does not remove the sections using the relocations, then yes.

> 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)

I think that this would be bad idea.  It would break the strict 
section/relocation relationship, which could lead to all kinds of
trouble.

Cheers
        Nick