Relocation to discarded sections from DWARF

[Andrew Burgess]

Hi,

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.

The specific example I am trying to solve first is the .debug_ranges 
section.  This describes the lower and upper bounds of disjoint areas of 
code belonging to a compilation unit.  The .debug_ranges is a list of 
start and end addresses with a special entry (start == end == 0) 
indicating the end of the list.  When an input section has been garbage 
collected the relocations to that sections are ignored / zero'd in the 
final output, and the result is a premature end of list marker.

My plan was to give bfd enough knowledge to remove unneeded relocations 
and bytes from the input .debug_ranges sections, this seemed (to me) to 
be in the same spirit as how we handle similar changes to eh_frame and 
stabs sections in bfd_elf_discard_info.

So, am I right to think what I am trying to achieve is a similar to the 
handling of eh_frame/stabs? Or is there something I'm not understanding?

Next, I tried to solve this by hooking into the backend-data 
elf_backend_discard_info function for my target.  I can indeed see all 
the required information and can see which relocations I would like to 
remove, however, when I try removing them I run into problems later 
during the final_link as it looks like I've not correctly reduced the 
number of relocations.

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?

I do have my current code which I could post, but honestly, I think I'm 
currently approaching the problem in the wrong way so it's probably more 
useful to try and figure out the right approach first before posting code.

Thanks for any help,

Andrew