Getting rid of BFD section->_raw_size and section->_cooked_size

[Hans-Peter Nilsson <hp at bitrange dot com>]

A few words about the section-size changes, before I go too far.
I've done some of the changes I describe below.  Enough I hope, to have
found all kinds of misuses of the current interface, as well as a useful
and maintainable set of changes.

Ever since I first noticed them, I've held a grudge against the
section->(raw_size, _cooked_size) members and their associated functions
and macros.  The _raw_size member is supposedly corresponding to the size
of the section in the input file, while _cooked_size is the one altered by
section relaxations, and should be used after relocation.  Or is it
actually after *relaxation*?  Who knows, or really, why should anyone need
to know?  For any sane definition, the uses are mixed up anyway.
Alan Modra suggested using a base size and a difference, which seems a
good idea.

One way to read and to set the size, should be all that's needed for
non-relaxing use.  The existing functions/macros bfd_section_size
(returning size + difference) and bfd_set_section_size (setting size,
clearing difference) seems good enough for an interface.

For relaxing use, there's a need to refer to the unaltered section size,
so we need something like bfd_unaltered_section_size (returning size
without difference) and bfd_alter_section_size (setting difference).

To wit, bfd_set_section_size sets the section size(!) and
bfd_alter_section_size changes that size, i.e. with regards to the last
call to bfd_set_section_size.  bfd_unaltered_section_size returns what
bfd_set_section_size set, while bfd_section_size returns the
possibly-altered size.  There should be no direct access to the section
struct members.

When we're here, let's drop the sec->reloc_done member; it's used nowhere
besides the current bfd_get_section_size_after_reloc where's it's choosing
between _cooked_size and abort, and it's confused everywhere it is set.

I'll try and tabulate the changes I propose:

Instead of		Use

(read) sec->_raw_size	bfd_section_size (abfd, sec)
			(or in relaxing targets and just when referring to
			original size:)
			bfd_unaltered_section_size (abfd, sec)

(write) _raw_size	bfd_set_section_size (abfd, sec, size)

(read) _cooked_size	bfd_section_size (abfd, sec)

(write) _cooked_size	bfd_alter_section_size (abfd, sec, newsize)

bfd_get_section_size_before_reloc (sec)
			bfd_section_size
			(or as mentioned above, actually rarely:)
			bfd_unaltered_section_size
bfd_get_section_size_after_reloc (sec)
			bfd_section_size

Most uses of bfd_unaltered_section_size and bfd_alter_section_size would
be in a relaxing target's get_relocated_section_contents, relax_section
and relocate_section functions.  Everyone else uses bfd_section_size and
bfd_set_section_size.

One caveat: this means a simple
 sec->_cooked_size -= count
would look a bit too unwieldy and more than twice as long, often causing
line breaks:
 bfd_alter_section_size (abfd, sec, bfd_section_size (abfd, sec) - count)

The need to avoid this readability regression seems to outweigh an
increased interface complexity.  So let's also have official helper
functions or macros to make this look instead like:
 bfd_incr_section_size (bfd, ptr, -count)
This makes code just a fraction longer after the change.
Similarly, setting the section reference size incrementally,
which is often done when linking, creating dynamic-section contents:
 bfd_incr_set_section_size (bfd, ptr, -count)

Macros are short enough to show here:
#define bfd_incr_section_size(bfd, ptr, incr) \
  bfd_alter_section_size (bfd, ptr, bfd_section_size (bfd, ptr) + incr)
#define bfd_incr_set_section_size(bfd, ptr, incr) \
  bfd_set_section_size (bfd, ptr, bfd_section_size (bfd, ptr) + incr)

The names have been chosen for mnemonicness: "incr" implies altering the
section size by an increment, while the second macro's "set" makes it look
similar to bfd_set_section_size, which it augments.

Would these changes be good or evil, or just unhelpful?
Thoughts?

brgds, H-P