Linker relaxation and the size of the output section
Hans-Peter Nilsson
hp@bitrange.com
Wed Oct 8 03:59:00 GMT 2003
On Wed, 8 Oct 2003, Alan Modra wrote:
> sec->_raw_size + sec->delta_size
>
> Faster, simpler, and allows output size to shrink to zero. Do you feel
> like doing a little editing? :-)
Uh, yes, seems like a good idea: I could do that. Just please
rather not now, while testing and splitting up the current batch
of relaxation patches.
Do you have a suggestion for test coverage of such a change? A
few targets implement relaxation. Some even have tests, but
they're often broken. :-/ I'll do ia64-*-linux-gnu gcc bootstrap
and make check of a combined tree besides the upcoming MMIX
tests.
> Hmm, the following uses of _cooked_size outsize of bfd/ and ld/ are a
> little dubious (or at least unnecessary). I'm fairly certain that
> nothing beside the linker needs to look at _cooked_size.
>
> ./gprof/corefile.c: + core_syms[i]->section->_cooked_size - 1, max_vma);
> ./gdb/hppa-tdep.c: && sec->vma + sec->_cooked_size < pc)
> ./sim/mcore/interp.c: (unsigned long) s_bss->vma , (unsigned long) s_bss->_cooked_size);
> ./sim/mcore/interp.c: heap_ptr = (unsigned long) s_bss->vma + (unsigned long) s_bss->_cooked_size;
Maybe related to the widespread misunderstanding of the meaning
of _cooked_size. Some BFD parts say it's valid after
relocation, others say it's valid after relaxation. It's
logically the latter and that's where it's set to anything else
than _raw_size. Note the therefore-misnamed
bfd_get_section_size_before_reloc and
bfd_get_section_size_after_reloc testing reloc_done and
returning _raw_size and _cooked size, respectively. The
difference matters in the small temporal window between
relaxation and relocation.
brgds, H-P
More information about the Binutils
mailing list