This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ambiguous file formats coff-x86_64 / pe-x86_64


>>> On 03.01.17 at 13:00, <amodra@gmail.com> wrote:
> 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.

Hmm, no, I don't think so: pe_bfd_object_p() identifies a PE
image (an executable), yet here we want to identify COFF
objects (one of two flavors - the one used in the Unix world,
and the one used in the Windows world, as produced by e.g.
MS and Intel compilers there). COFF_WITH_PE distinguishes
those two flavors.

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]