From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16403 invoked by alias); 15 Aug 2011 13:25:49 -0000 Received: (qmail 16387 invoked by uid 22791); 15 Aug 2011 13:25:47 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 13:25:32 +0000 Received: (qmail 24951 invoked from network); 15 Aug 2011 13:25:31 -0000 Received: from unknown (HELO tp.orcam.me.uk) (macro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Aug 2011 13:25:31 -0000 Date: Mon, 15 Aug 2011 13:25:00 -0000 From: "Maciej W. Rozycki" To: Alan Modra cc: Catherine Moore , binutils@sourceware.org Subject: Re: [RFA] PowerPC VLE port In-Reply-To: <20110813114725.GH19463@bubble.grove.modra.org> Message-ID: References: <4E456B7A.4020105@codesourcery.com> <20110813114725.GH19463@bubble.grove.modra.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 X-SW-Source: 2011-08/txt/msg00124.txt.bz2 On Sat, 13 Aug 2011, Alan Modra wrote: > -/* This bit is reserved by BFD for processor specific stuff. Name > - it properly so that we can easily stay consistent elsewhere. */ > -#define SEC_PPC_VLE SEC_TIC54X_BLOCK > > Please revert this accidental commit now rather than waiting until the > whole patch is approved. Not accidental at all. This bit is used in bfd/coffcode.h like this: #ifdef STYP_BLOCK if (sec_flags & SEC_TIC54X_BLOCK) styp_flags |= STYP_BLOCK; #endif that is potentially for any target defining STYP_BLOCK. I can see that STYP_BLOCK is only defined by include/coff/ti.h, so the overloading of this flag like this should be safe after all, but I find this confusing and I think that while the macro can indeed use the bit occupied by SEC_TIC54X_BLOCK, a couple of adjustments should be made: 1. STYP_BLOCK (and consequently STYP_CLINK) should be renamed STYP_TIC54X_BLOCK (STYP_TIC54X_CLINK) to indicate they are target-specific. 2. The definition of SEC_TIC54X_BLOCK (and SEC_TIC54X_CLINK) in bfd/section.c replaced with SEC_BACKEND_1 (and SEC_BACKEND_2) or suchlike, to indicate these two bits are backend-specific, and the two former macros only defined by the include/coff/ti.h, in terms of the two latters (respectively). 3. Likewise SEC_PPC_VLE (and SEC_MEP_VLIW) redefined in terms of SEC_BACKEND_1. Do you agree? > > +. {* Indicate that the section has the VLE bit set. *} > > +.#define SEC_PPC_VLE 0x80000000 > > +. > > Where is this used? If needed, I'd rather see one of the sec_flg[0-6] > bits used instead for backend specific flags. OK, so should we keep this flag or not after all, hmm? It looks to me like the removal above you've objected is good either way. :) Maciej