From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94485 invoked by alias); 23 May 2016 09:42:02 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 93892 invoked by uid 89); 23 May 2016 09:42:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=02AM, 02am X-HELO: mail-pa0-f65.google.com Received: from mail-pa0-f65.google.com (HELO mail-pa0-f65.google.com) (209.85.220.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 23 May 2016 09:42:00 +0000 Received: by mail-pa0-f65.google.com with SMTP id rw9so17367069pab.2 for ; Mon, 23 May 2016 02:41:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=60q4aAv986M3v4Zxr8taqn5m2m7vaB4qhoEiMM1q834=; b=LKw1rWKraZa16N5ZD4s3DJjB5/o09OSACsCRfnOGv/OhdC0VREKby3aCbabBPrObRU MivHOYo1EabNNitO9LgaMBmRMVZCMjZCNE35IDuTIIoWoOJzXHj7kqvxiLaD8b64LAlD S0RSR0d2pRRI3jsTmU/wA1lCiaARnCgARAJmh7mptz0SuAEq4PFBi925Xgd3NP6zn1bq DePlghTbs8icDok5/1i5T4/LozxixLOFAKE3NON6VHaN2+p0rC1aNGN72wX3/49xeaYP SWL6SQKkSMYaDQP+qa0pHb2qhpibVYkCMY1a7pt96qy/qnLdo7aSPtvKDw7P3QQPGg2d o4cw== X-Gm-Message-State: AOPr4FU3DOGnDSv4f8V239ykkam3HM4DdVScsSdIgMscWCo8fEjki4maIlOhovrcsqnkwQ== X-Received: by 10.66.159.102 with SMTP id xb6mr25614782pab.73.1463996518285; Mon, 23 May 2016 02:41:58 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-146-233.sa.bigpond.net.au. [58.160.146.233]) by smtp.gmail.com with ESMTPSA id 28sm45124354pfr.89.2016.05.23.02.41.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 May 2016 02:41:57 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 4703FEA0199; Mon, 23 May 2016 19:12:03 +0930 (ACST) Date: Mon, 23 May 2016 09:42:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: binutils@sourceware.org Subject: Re: [PATCH] PR binutils/14625: Enable 64-bit archives in ar and ranlib Message-ID: <20160523094203.GC3300@bubble.grove.modra.org> References: <20160520121002.GA28605@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160520121002.GA28605@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00341.txt.bz2 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. > + # 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? 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 with the coff defines substituted. eg. _bfd_slurp_extended_name_table rather than _bfd_archive_coff_slurp_extended_name_table. -- Alan Modra Australia Development Lab, IBM