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...]
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.
> Anyway, the things that I wondered about are:
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.
> 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.
> bfd_get_relocated_section_contents now return a real block of zeroed memory
> when we try it with the COMMON section?
It will return zeroed memory, assuming that the COMMON section has
SEC_HAS_CONTENTS clear (which it should).
> 2) The subsequent call to bfd_set_section_contents uses link_order->offset
> and link_order->size, are we always 100% guaranteed that this will never
> exceed the sec_size calculated for the input section?
I think so, but I'll not give you a 100% guarantee. :)
> 3) bfd_malloc doesn't zero the allocated memory; in your patch, if the raw
> size is less than the nominal cooked size, shouldn't the end of the
> allocation (the difference between the size we allocate and the amount we
> actually read in with bfd_get_relocated_section_contents) be cleared to
> zero?
On mainline, when "rawsize" is zero bfd_get_relocated_section_contents
returns "size" worth of contents, not "rawsize".
--
Alan Modra
IBM OzLabs - Linux Technology Centre