This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFC: Implicit DWARF relocs


Hi!

I've looked at the DWARF Fission proposal and to me it looks that lots of
efforts is spent on decreasing the size of the debug info related relocations
on ET_REL objects, often (at least in my understanding) at the cost of
increasing the debug info (but by smaller amount than the saving on the size
of relocations).

I wonder if we couldn't for the reduction of relocation size against 
.debug_info/.debug_types/.debug_macro sections and maybe .debug_loc use a
different approach.  The DWARF sections are structured and DWARF consumers
know where to relocate things, so why couldn't the linker?

The compiler, if it detects linker support, could (through assembler
extensions) set 
#define SHF_GNU_DWARF_IMPLICIT_RELOCS	(1 << 20)
bit in sh_flags and set sh_info to algorithm version for the implicit relocs
(say 1 at the beginning) and then omit some relocations against other
.debug_* sections in the assembly it creates.

The linker (in ld.bfd I guess e.g. _bfd_elf_link_read_relocs could do that)
would then add implicit relocations where the compiler omitted them
(and for ld -r adjust them and not store again), using a simple algorithm.

The .debug_info (and similarly .debug_types) algorithm would be, for the
.debug_info section find corresponding .debug_str, .debug_loc, .debug_line,
.debug_ranges and .debug_abbrev sections if available, where corresponding
would be for .debug_info in a comdat group look for those named sections
in the same comdat group first, then fall back to the named sections not in
comdat, for non-comdat non-comdat named sections only.
Then qsort all the explicit relocations against the section by increasing
offset, then walk the section.  If abbrev offset field in the DWARF CU
header doesn't have explicit relocation against it, add implicit one against
corresponding .debug_abbrev section + addend stored in that memory location.
Parse abbrevs into an array or hash table or combined data structure, walk
the CU content.  If DW_FORM_strp location doesn't have explicit reloc,
assume corresponding .debug_str + addend in that 4 byte field.
If DW_FORM_sec_offset location doesn't have explicit reloc, assume
.debug_{line,ranges,loc} + addend in that field for DW_AT_stmt_list,
{DW_AT_ranges,DW_AT_start_scope} resp. other attributes.
Anywhere where the implicit reloc would do a wrong thing the producer must
supply an explicit relocation.

Of course the linker would need to be strict on erroring out on anything
unexpected (unknown DW_FORM_*, etc.).  The consumer would need to avoid
using implicit relocs if it uses forms that the linker might not understand
based on the requested algorithm version.

The .debug_macro algorithm would handle similarly DW_FORM_strp values in the
section if they don't have explicit reloc.

And, maybe .debug_loc could have an algorithm where for the address fields
in the section remembers last relocation against an address field if any,
and if an address field isn't ~0 or 0, implicitly relocate it relative
to the last address field relocation - 1 (the - 1 bias so that we never get
there 0).  Perhaps it should do it only until terminating 0, 0, and stop
also on ~0, something.  In .debug_loc we have an alternative, let the
producer for DW_AT_low_pc 0 (have_multiple_text_sections in dwarf2out.c,
which is quite often these days) emit ~0, base entries first, but that
wastes 64 or 128 bits in the section on each location list to get rid of
most of the relocations.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]