This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: RFA: Your patch from 2004-06-29 (bfd/linker.c rev 1.37) [was RE: COMMON symbols...]
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Alan Modra'" <amodra at bigpond dot net dot au>
- Cc: <binutils at sourceware dot org>
- Date: Tue, 5 Apr 2005 11:47:00 +0100
- Subject: RE: RFA: Your patch from 2004-06-29 (bfd/linker.c rev 1.37) [was RE: COMMON symbols...]
----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....