DWARF updates for linker relaxation?

[Bob Wilson <bwilson at tensilica dot com>]

I recently discovered a problem on Xtensa regarding DWARF line numbers and 
linker relaxation.  I'm not sure, but it looks like the same issue may exist for 
SH and possibly other ports that do link-time relaxation.  Before I go too far 
trying to solve this, I'd like to see if anyone has already looked at it, or if 
anyone has suggestions for solutions.

Link-time relaxation for Xtensa may cause some instructions to be deleted.  We 
rely on the assembler's (Xtensa-specific) -link-relax option to produce 
relocations for all text offsets that may change.  The thing we're missing is 
the address offsets in .debug_line sections (e.g., "special opcodes" that 
advance the address by a certain amount).  The assembler does not emit 
relocations for these offsets, and the linker does not adjust them when deleting 
instructions.

This problem went unnoticed for a while, because Tensilica's compiler produces 
its own DWARF that has relocations for the address offsets.  It isn't clear to 
me whether the DWARF generated by the assembler has ever worked with link-time 
relaxation on Xtensa, or if this is a regression caused by some change in the 
assembler.

I've looked around in the code to see if anyone else has dealt with this, and it 
looks like the SH port has code related to this.  See, for example, the 
sh_elf_relax_delete_bytes() function, which appears to be used to delete an 
instruction during linker relaxation.  That function contains this comment: 
"Dwarf line numbers use R_SH_SWITCH32 relocs."  This makes sense to me, since 
those relocs can represent an address offset, and the linker can look for those 
relocs to update the DWARF information.  The problem is that I can't find 
anything in the SH port of the assembler that would cause SWITCH32 relocs to be 
use for DWARF line numbers.  When I run the SH assembler, I don't see any of 
these relocations in the .debug_line section, either.

How do I make this work?  It seems like the obvious approach is to have a hook 
in the assembler to make it use the generic "advance_pc" opcode instead of 
"special opcodes", with relocations on the address offset fields.  The SH code 
mentioned above made me think there might already be code for this somewhere in 
the assembler, but I haven't found it.

Any suggestions?

--Bob