This is the mail archive of the binutils@sources.redhat.com 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]

Re: _cooked_size usually set when/where?


On Wed, 31 Mar 2004, Alan Modra wrote:

> On Tue, Mar 30, 2004 at 04:36:42PM -0600, Brian Ford wrote:
> > On Tue, 30 Mar 2004, Alan Modra wrote:
> > > On Mon, Mar 29, 2004 at 04:33:37PM -0600, Brian Ford wrote:
> > > > So, my question is, when is _cooked_size usually set up and by whom?
> > >
> > > ldlang.c:lang_size_sections_1, and perhaps earlier, eg.
> > > ldemul_before_allocation.
> >
> > Thanks for the reply.  Those set the output section's _cooked_size right?
>
> No, they set input section _cooked_size too.
>
Ok, I was going by the comment above lang_size_sections_1:

/* Set the sizes for all the output sections.  */

and by the observation that in my previously reported problem, neither
have been called before the abort.

> As an aside, I think the current use of _raw_size and _cooked_size in
> binutils is a bit of a mess.  My main dislike is numerous places that
> use _cooked_size if non-zero and use _raw_size otherwise.  In the past
> I've advocated using _raw_size and an adjustment, initially zero, in
> all places that use _cooked_size.  You could do the same thing by
> writing/reading _cooked_size in all places *except* for places that
> really want the original on-disk size of input sections.  This is a
> simple conceptual change, but changing bfd to use this scheme is tedious
> and likely to introduce errors as there are many places that
> (incorrectly) change _raw_size to something other than the original
> section size.

I whole-heartedly agree.  And, I was excited by Nans-Peter Nilsson's
proposal to revamp this back in October.  I do understand the fragile
nature of this sort of change, though.

As an "outsider", I can tell you that this causes me no end of confusion
when I try to properly fix bugs and add features.  In some ways, I guess
this is how companies like Red Hat get business (ha, ha).  Well, that
kind of confusion caused us to require their assistance recently at
least ;-).

However, given my current problem and lack of "big picture" understanding,
the simplest way for me to fix it is to add just such a hack.  ie:

reloc.c (bfd_generic_get_relocated_section_contents) line 4302:

if (input_section->_cooked_size == 0)
  input_section->_cooked_size = input_section->_raw_size;

Please suggest an alternative.  I'm all ears.  But, so far, I've been
unsuccessful in finding one, at least not by comparing PE/COFF to Linux
ELF and trying to find differences :-).

Thanks again.  I've been looking hard to find the "right" fix, but it is
becoming prohibitively expensive for me to do so.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444


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