From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16977 invoked by alias); 16 Oct 2011 03:29:23 -0000 Received: (qmail 16967 invoked by uid 22791); 16 Oct 2011 03:29:22 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 16 Oct 2011 03:29:08 +0000 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 15 Oct 2011 20:29:07 -0700 X-ExtLoop1: 1 Received: from tassilo.jf.intel.com ([10.7.201.108]) by azsmga001.ch.intel.com with ESMTP; 15 Oct 2011 20:29:07 -0700 Received: by tassilo.jf.intel.com (Postfix, from userid 501) id 6A6CE240F46; Sat, 15 Oct 2011 20:29:07 -0700 (PDT) From: Andi Kleen To: "H.J. Lu" Cc: GCC Development , Binutils Subject: Re: RFC: Add --plugin-gcc option to ar/nm References: Date: Sun, 16 Oct 2011 14:30:00 -0000 In-Reply-To: (H. J. Lu's message of "Sat, 15 Oct 2011 15:44:46 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00239.txt.bz2 "H.J. Lu" writes: > Hi, > > ---plugin option for ar/nm is very long. I am proposing to add > a --plugin-gcc option. It can be implemented with > > 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4. > 2. Define LTOPLUGINSONAME for ar/nm. > 3. For --plugin-gcc, ar/nm call popen using environment variable GCC if set, > or gcc with -print-prog-name=$LTOPLUGINSONAM to get > plugin name. > > Any comments? I had some old patches for gcc-ar, gcc-nm etc. That's similar how other compilers do it. http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02471.html With that it doesn't matter how long the option is. The original feedback was that shell wrapper were not portable enough. I actually did C based wrappers recently, but haven't submitted them yet. I think wrappers are preferable over shorter options because they are easier to use and easier to fit into existing makefiles. The best long term direction probably would be to put a reference to the plugin into the object files and let BFD find it itself. This would be most compatible with existing Makefiles. But that would need more work. -andi -- ak@linux.intel.com -- Speaking for myself only