This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ambiguous file formats coff-x86_64 / pe-x86_64
On Tue, Jan 03, 2017 at 04:22:47AM -0700, Jan Beulich wrote:
> >>> On 03.01.17 at 11:27, <amodra@gmail.com> wrote:
> > On Tue, Jan 03, 2017 at 12:32:37AM -0700, Jan Beulich wrote:
> >> >>> On 22.12.16 at 22:49, <amodra@gmail.com> wrote:
> >> > On Thu, Dec 22, 2016 at 07:43:39AM -0700, Jan Beulich wrote:
> >> >> binary. We've now had reports that on binutils with both coff-x86_64
> >> >> and pe-x86_64 configured in (but defaulting to ELF), linking fails due
> >> >> to the object being ambiguous.
> >> >
> >> > match_priority was invented for exactly this sort of situation.
> >>
> >> Interesting: I don't see how that would help here, as I don't see
> >> why (and on what basis) to "prefer" one variant over the other.
> >> Looking over the source, at least relocation addend handling is
> >> different between the two, and without other (sideband?) info
> >> I don't think one can guess the format to be used. The situation
> >> in our case is different, because we don't care which of the two
> >> gets used, ad we don't care about their differences.
> >
> > Hmm, I wonder why coff-x86_64.c has
> >
> > #ifdef PE
> > #define amd64coff_object_p pe_bfd_object_p
> > #else
> > #define amd64coff_object_p coff_object_p
> > #endif
> >
> > and not #ifdef COFF_WITH_PE?
>
> Indeed I had been surprised by this apparent inconsistency too,
> but I've assumed whoever wrote this knew why (s)he was doing
> it this way. But then I don't think changing the symbol used would
> affect the behavior which is problematic to us.
Well, as it is, you have both coff-x86_64 and pe-x86_64 using
coff_object_p. Seems wrong to me.
--
Alan Modra
Australia Development Lab, IBM