ambiguous file formats coff-x86_64 / pe-x86_64

ambiguous file formats coff-x86_64 / pe-x86_64

[Jan Beulich]

Hello,

in the Xen Project we've recently switched to linking in a trivial COFF
object to trigger the COFF/PE build ID machinery when building an EFI
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. Afaict (from going through config.bfd)
it is not safe to force the object type to either of the two types, as
each of the two could be unavailable in a particular binutils build (the
only requirement is pei-x86_64 to be available, which different
targets select together with one or the other).

Are there ways to cleanly deal with this situation? Is there perhaps
a way to tell the linker to prefer one format when both are available?
The object file contains no sections or symbols, and hence it is -
afaict - completely benign which of the two formats it would get
handled with.

I'd like to avoid the uglier approach of scanning the list of
supported targets from the help output of one of the tools, or
trying one and falling back to the other if the first fails ...

Thanks, Jan

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

[Alan Modra]

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.

-- 
Alan Modra
Australia Development Lab, IBM

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

[Jan Beulich]

>>> 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.

Jan

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

[Alan Modra]

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?

-- 
Alan Modra
Australia Development Lab, IBM

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

[Jan Beulich]

>>> 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.

Jan

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

[Alan Modra]

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

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

[Jan Beulich]

>>> 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