This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: PE COFF relocation overflow bug
On Sun, Jul 07, 2002 at 07:43:43PM -0000, Mark Mitchell wrote:
> --On Sunday, July 07, 2002 9:20 PM +0930 Alan Modra <amodra@bigpond.net.au>
> wrote:
> >Either this patch, or coffcode.h:coff_write_relocs is wrong, as the
>
> The coffcode.h one is wrong. I checked this with the Microsoft compiler.
> (And, if you think about it, the only consistent choice is >=; the 0xffff
> tells you that you need to look in the relocation table. ) I can make
> that change too, if you want.
Please. They need to be consistent.
> >latter adds the extra reloc for reloc_count > 0xffff. Also, it seems
> >to me that you should be allocating the extra space #ifdef COFF_WITH_PE
> >rather than when obj_pe.
>
> That doesn't work; this file is not #include'd elsewhere -- it's only
> compiled once. So, you need a runtime check; hence obj_pe.
Hmm, it wouldn't be the first occurrence of #ifdef COFF_WITH_PE in
cofflink.c
> Unless that doesn't do what I think it does...
That's what was worrying me. peicode.h:pe_ILF_build_a_bfd sets obj_pe.
This function is called from pe_ILF_object_p, which in turn is called
from pe_bfd_object_p. Examining pe_bfd_object_p shows that it also
handles standard coff objects. I don't think coffcode.h is compiled
twice when enabling a pe target, once for pe variety, once for coff.
So coffcode.h:coff_write_relocs checks reloc_count > 0xffff for both
pe and coff objects, when configuring for a pe target. That's why I
suggested #ifdef COFF_WITH_PE, for consistency. Of course, this might
just be consistently wrong...
Better might be to use obj_pe in all places that twiddle reloc_count.
That way you could configure for a pe target and have some hope of
building a coff object with 0xffff relocs.
--
Alan Modra
IBM OzLabs - Linux Technology Centre