On Tue, May 24, 2016 at 10:03 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, May 23, 2016 at 2:42 AM, Alan Modra <amodra@gmail.com> wrote:
>> On Fri, May 20, 2016 at 05:10:02AM -0700, H.J. Lu wrote:
>>> Since existing ld and gold support the 64-bit (MIPS) ELF archives, we
>>> can use the 64-bit (MIPS) ELF archives as 64-bit archives.  Since the
>>> plugin target is used to create archive in plugin-enabled ar, we need
>>> a way to enable 64-bit archives in the plugin target.  This patch adds
>>> --enable-64-bit-archive to bfd to enable 64-bit archives in ar and
>>> ranlib.  Since both 64-bit MIPS and s390 ELF targets currently use
>>> 64-bit archives, all Linux linkers with 64-bit BFD support both 32-bit
>>> and 64-bit archives, 64-bit archives are enabled by default for them.
>>
>> Hmm, isn't it true that archive64.c is compiled in for any 64-bit
>> target?  I also don't see anything ELF specific in archive64.c.
>
> That is correct.
>
>>> +  # Since all Linux linkers support both 32-bit and 64-bit archives,
>>> +  # it is safe to enable 64-bit archives for Linux targets with 64-bit
>>> +  # bfd_vma.
>>> +  case "${target}${want64}" in
>>> +    *linux*true)
>>> +      want_64_bit_archive=true
>>> +      ;;
>>> +  esac
>>> +fi
>>
>> So the above could just set want_64_bit_archive based on want64,
>> ignoring target, except that doing so might result in archives that
>> aren't recognized by native tools.  How about instead of this
>> configure option, changing _bfd_compute_and_write_armap to choose the
>> archive64.c write_armap whenever the archive size is larger than 2G?
>
> The limit is 4GB, not 2GB.  The limit is the offset of an archive member,
> not the size of archive.  We can have an archive > 4GB with archive
> member offsets < 4GB.
>
>> I think that might just work automatically.
>>
>> The rest of the patch looks reasonable except that you missed changing
>> elf64-ia64-vms.c, and I think the libbfd-in.h defines would be better
>
> Since elf64-ia64-vms.c uses _bfd_vms_lib_write_armap which is defined as
> NULL, i prefer to leave it unchanged.
>
>> with the coff defines substituted.  eg. _bfd_slurp_extended_name_table
>> rather than _bfd_archive_coff_slurp_extended_name_table.
>>
>
> Good point.  Here is the updated patch.  OK for master?
>

This patch generates 64-bit archive automatically.


-- 
H.J.