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] | |
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-8444Attachment:
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] |