linking EFI binary from ELF objects and archives

linking EFI binary from ELF objects and archives

[Jan Beulich]

Nick,

in PR 22369 you said

"I do wonder if we should issue an error message when attempting to
 perform cross-format links like this.  Although in theory of course
 the library could contain both COFF format objects and ELF format
 objects.  Which makes things a little more complicated.  Hmm, maybe
 I need to think about this."

Am I correctly understanding that while linking EFI binaries (i.e.
PE32+) from ELF _objects_ works, trying to also have _archives_ of
ELF objects involved doesn't? coff_link_check_archive_element()
looks to also confirm this suspicion (and observation), but then
again I'm not sure I'm not missing something else (like a magic
command line option making this work).

If this doesn't currently work, making it work wouldn't really help
for my purpose (as it also needs to work with older binutils), so
I'd then be looking for alternatives. Is behavior of "ld -r" well
defined when it comes to including archives? I.e. would the output
object have all necessary (and just those) objects pulled in from
the archive in order to satisfy undefined symbols? And if the
answer was yes, would you know whether this holds for sufficiently
old binutils (say 2.16 / 2.17-ish)?

As an aside - while looking at coff_link_check_archive_element() I
got puzzled by

  /* If the archive element has already been loaded then one
     of the symbols defined by that element might have been
     made undefined due to being in a discarded section.  */
  if (((struct coff_link_hash_entry *) h)->indx == -3)
    return TRUE;

  /* PR 22369 - Skip non COFF objects in the archive.  */
  if (! bfd_family_coff (abfd))
    return TRUE;

Shouldn't these two checks be the other way around, for the cast in
the first if() to be valid at all? Or is h's layout controlled by
the output format?

Jan

Re: linking EFI binary from ELF objects and archives

[Nick Clifton]

Hi Jan,

> in PR 22369 you said
> 
> "I do wonder if we should issue an error message when attempting to
>  perform cross-format links like this.  Although in theory of course
>  the library could contain both COFF format objects and ELF format
>  objects.  Which makes things a little more complicated.  Hmm, maybe
>  I need to think about this."
> 
> Am I correctly understanding that while linking EFI binaries (i.e.
> PE32+) from ELF _objects_ works,

Actually I do not think that this does work.  The PR was for a case
where this was attempted, and a seg-fault was generated.  But I
think that even if the seg-fault had not happened the link still 
would have failed.

> As an aside - while looking at coff_link_check_archive_element() I
> got puzzled by
> 
>   /* If the archive element has already been loaded then one
>      of the symbols defined by that element might have been
>      made undefined due to being in a discarded section.  */
>   if (((struct coff_link_hash_entry *) h)->indx == -3)
>     return TRUE;
> 
>   /* PR 22369 - Skip non COFF objects in the archive.  */
>   if (! bfd_family_coff (abfd))
>     return TRUE;
> 
> Shouldn't these two checks be the other way around,

Yes - this is a bug...  I am testing the obvious fix now and
if nothing goes wrong I will check the patch in later today.

Cheers
  Nick

Re: linking EFI binary from ELF objects and archives

[Jan Beulich]

On 09.09.2020 14:49, Nick Clifton wrote:
>> in PR 22369 you said
>>
>> "I do wonder if we should issue an error message when attempting to
>>  perform cross-format links like this.  Although in theory of course
>>  the library could contain both COFF format objects and ELF format
>>  objects.  Which makes things a little more complicated.  Hmm, maybe
>>  I need to think about this."
>>
>> Am I correctly understanding that while linking EFI binaries (i.e.
>> PE32+) from ELF _objects_ works,
> 
> Actually I do not think that this does work.

Why? We've been using it successfully in the Xen project to build
Xen as an EFI binary, alongside a traditional ELF one, and both
from mostly the same object files.

>  The PR was for a case
> where this was attempted, and a seg-fault was generated.  But I
> think that even if the seg-fault had not happened the link still 
> would have failed.

It was my understanding that the issue at the time was with an
archive containing ELF objects, not an individual object.

Apart from this - any word on my question on "ld -r" when it comes
to archives?

Jan

Re: linking EFI binary from ELF objects and archives

[Alan Modra]

On Wed, Sep 09, 2020 at 01:49:34PM +0100, Nick Clifton via Binutils wrote:
> > 
> >   /* If the archive element has already been loaded then one
> >      of the symbols defined by that element might have been
> >      made undefined due to being in a discarded section.  */
> >   if (((struct coff_link_hash_entry *) h)->indx == -3)
> >     return TRUE;
> > 
> >   /* PR 22369 - Skip non COFF objects in the archive.  */
> >   if (! bfd_family_coff (abfd))
> >     return TRUE;
> > 
> > Shouldn't these two checks be the other way around,
> 
> Yes - this is a bug...  I am testing the obvious fix now and
> if nothing goes wrong I will check the patch in later today.

Since those particular "h" came from link_info.hash, they are in the
output file format regardless of the input bfd.  So not a bug, but it
is of course fine to flip the ordering of the tests.

-- 
Alan Modra
Australia Development Lab, IBM

Re: linking EFI binary from ELF objects and archives

[Alan Modra]

On Wed, Sep 09, 2020 at 02:56:08PM +0200, Jan Beulich wrote:
> Apart from this - any word on my question on "ld -r" when it comes
> to archives?

It should work as you might expect, with archive elements extracted to
satisfy undefined symbol references.

-- 
Alan Modra
Australia Development Lab, IBM