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