From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5134 invoked by alias); 10 Mar 2005 17:09:58 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 5067 invoked from network); 10 Mar 2005 17:09:51 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 10 Mar 2005 17:09:51 -0000 Received: (qmail 29389 invoked from network); 10 Mar 2005 17:09:50 -0000 Received: from localhost (HELO taltos.codesourcery.com) (zack@127.0.0.1) by mail.codesourcery.com with SMTP; 10 Mar 2005 17:09:50 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Thu, 10 Mar 2005 09:09:50 -0800 To: Richard Earnshaw Cc: binutils@sources.redhat.com Subject: Re: PATCH: Additional Thumb instructions for ARMv6K References: <87u0nlhb09.fsf@codesourcery.com> <1110368381.14453.38.camel@pc960.cambridge.arm.com> From: Zack Weinberg Date: Thu, 10 Mar 2005 17:09:00 -0000 In-Reply-To: <1110368381.14453.38.camel@pc960.cambridge.arm.com> (Richard Earnshaw's message of "Wed, 09 Mar 2005 11:39:42 +0000") Message-ID: <87y8cvl95u.fsf@codesourcery.com> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-03/txt/msg00307.txt.bz2 Richard Earnshaw writes: > Hmm, I think we've got a problem here. Gas is normally configured to > default to the pseudo CPU 'all' which permits instructions from any > architecture. That means that unless the user has explicitly set a cpu > (or gcc has done it for you) then the new nop will match rather than the > old (because of the way the selection logic works as a bit-field and > mask). > > I'm not sure that's desirable because it might break existing code that > did not expect to have to supply a CPU option. I did notice this effect in testing, and it surprised me, but I wasn't sure what to do about it. > One partial solution is to pick some architecture ( 'all' mean anything up to that architecture -- anything after that must > supply a command-line flag (and we should add some configury magic to > permit selecting a specific cpu as the default). We could do this and > at the same time deprecate 'all' so that it could be ultimately removed. This sounds like a sensible solution, but I do not know what a reasonable default choice would be. > The changes other than the NOP work are OK to install (if they can > feasibly be separated out). I can split them out and resubmit, but it may be a couple of days before I get to it. zw