RE: RFA: Your patch from 2004-06-29 (bfd/linker.c rev 1.37) [was RE: COMMON symbols...]

["Dave Korn" <dave dot korn at artimi dot com>]

----Original Message----
>From: Alan Modra
>Sent: 05 April 2005 01:50

> On Mon, Apr 04, 2005 at 03:48:08PM +0100, Dave Korn wrote:
> [snip]
>>   This looks like it's already been addressed in mainline, as part of
>> your [snip] ... and here's what I did, since I'm running from somewhat
>> older sources (2.13.90 20030308, LOL!) ...
> [snip]
> You should really have owned up to this when you posted your first
> "COMMON symbols..." message.  Nick's answers may have been somewhat
> different.

  Yes, that was a bit remiss of me... although I think his answer was fairly
generic!

 > I didn't make the changes to the section size fields for the linker
> problem you have found.  It was a more general cleanup.  In the process,
> the meaning of the fields changed, so some of your questions don't
> really make sense.

  Yeh, I wasn't sure if it was entirely commensurable.... never mind.

>> 1)  You use the maximum of the input section's raw size and cooked size.
>> Are these values still zero for the COMMON section?  Or does
> 
> I think you'll find that size will be set as appropriate for the number
> of common symbols allocated in the section.  rawsize will be zero.

  I think this is actually the real crux of it.  If the size of the common
section had been set to the size determined during the
common-symbol-allocation stage, then bfd_get_relocated_section_contents
would have delivered us a block of zero-filled memory of that size, and
everything would have "just worked" (TM).  Anyway, thanks for your comments
:)


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....