This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Getting rid of BFD section->_raw_size and section->_cooked_size
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: binutils at sources dot redhat dot com
- Date: Wed, 22 Oct 2003 09:39:06 -0400 (EDT)
- Subject: Getting rid of BFD section->_raw_size and section->_cooked_size
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