Relocation to discarded sections from DWARF

nick clifton nickc@redhat.com
Tue Nov 29 12:08:00 GMT 2011
Hi Andrew,

> I am currently trying to extend bfd to help me with a problem I
> encounter when using -ffunction-sections to gcc, and --gc-sections to
> the linker.
>
> When creating DWARF debugging information in an ELF references from the
> debugging information to the code are usually created as relocations.
> When sections are removed due to --gc-sections this can sometimes result
> in invalid debugging information being created.

Hmm - it seems to me that this problem would go away if gcc emitted the 
debug information in function specific sections as well.  Ie when 
-ffunction-sections is enabled, instead of gcc generating just one 
.debug_line section containing all of the line number information it 
could create a series of .debug_line.{func_name} sections.  Then in the 
linker when --gc-sections discards .text.foo the relocations 
in.debug_line.foo would be noticed and that section discarded as well. 
Simples.


> So, am I right to think what I am trying to achieve is a similar to the
> handling of eh_frame/stabs?

Yes.


> Next, I tried to solve this by hooking into the backend-data
> elf_backend_discard_info function for my target.

This strikes me as being a bad move.  Discarding irrelevant line data 
information is a generic (to ELF/DWARF) issue, not a target specific 
issue.  Instead I think that the code ought to go into bfd/elflink.c 
and/or bfd/dwarf2.c.


> Looking through bfd_elf_discard_info, and the other users of
> elf_backend_discard_info I can't see any examples of how to remove
> relocations / content from the input section at this point. Is this the
> right stage to be doing such things?

Look at the linker relaxing code used by various backends.  (Eg: 
bfd/elf-m10300.c:mn10300_elf_relax_delete_bytes and 
mn10300_elf_relax_section).  Relocations are usually "removed" by 
changing their type to BFD_RELOC_NONE.


Cheers
   Nick



More information about the Binutils mailing list