From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6658 invoked by alias); 15 Sep 2002 04:39:35 -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 6651 invoked from network); 15 Sep 2002 04:39:34 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 15 Sep 2002 04:39:34 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id g8F4dT815954; Sun, 15 Sep 2002 00:39:30 -0400 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5) with ESMTP id g8F4dSsx006268; Sun, 15 Sep 2002 01:39:28 -0300 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.5/8.12.5/Submit) id g8F4dS61006264; Sun, 15 Sep 2002 01:39:28 -0300 To: Daniel Jacobowitz Cc: binutils@sources.redhat.com, echristo@redhat.com Subject: Re: MIPS assembler branch relaxations References: <20020914151121.GA7853@nevyn.them.org> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Sun, 15 Sep 2002 00:49:00 -0000 In-Reply-To: <20020914151121.GA7853@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00242.txt.bz2 On Sep 14, 2002, Daniel Jacobowitz wrote: > If this goes in as-is, I doubt that it'll ever be done the right way. I agree. I doubt it's worth doing it the right way. It shouldn't strike often enough to motivate anyone to do it. > Does it happen inside .set nomacro? [I think so - should it? I'd > say not!] I don't see why not. It's not like we're expanding a macro. We're rather doing relaxation. Does the linker refrain from doing relaxations on machine code generated from opcodes assembled while .set nomacro was in effect? This is no different, except that the relaxation is being performed in the assembler rather than in the linker. > I think there should be a command-line option to disable this, > and/or warn about it. That would be a nice improvement. Just arrange for whatever option you come up with to disable this block: if (place == NULL && address_expr && ((*reloc_type == BFD_RELOC_16_PCREL && address_expr->X_op != O_constant) || *reloc_type == BFD_RELOC_16_PCREL_S2) && (pinfo & INSN_UNCOND_BRANCH_DELAY || pinfo & INSN_COND_BRANCH_DELAY || pinfo & INSN_COND_BRANCH_LIKELY) + && !whatever_option_you_come_up_with && !mips_opts.mips16) This will switch all the rest off. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer