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]

[RFA/PATCH] auto-import errors & DWARF 2 (was Re: _cooked_sizeusually set when/where?)


Ok, I give up.  I can't find the "proper" fix for this.

2004-04-13  Brian Ford  <ford@vss.fsi.com>

        * simple.c (bfd_simple_get_relocated_section_content): Handle a
	_cooked_size of zero when auto-import errors look up DWARF 2 data.

Comments, alternatives, suggestions *please*?  Thanks.

On Wed, 31 Mar 2004, Brian Ford wrote:

> 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 Hans-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

Attachment: simple.patch
Description: Text document


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