From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28617 invoked by alias); 24 May 2010 22:25:45 -0000 Received: (qmail 28597 invoked by uid 22791); 24 May 2010 22:25:44 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from dns1.mips.com (HELO dns1.mips.com) (63.167.95.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 May 2010 22:24:56 +0000 Received: from MTVEXCHANGE.mips.com ([192.168.36.60]) by dns1.mips.com (8.13.8/8.13.8) with ESMTP id o4OMOquC027825; Mon, 24 May 2010 15:24:52 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] MIPS: microMIPS and MCU ASE instruction set support Date: Mon, 24 May 2010 22:25:00 -0000 Message-ID: <94BD67F8AF3ED34FA362C662BA1F12C502BB5F7F@MTVEXCHANGE.mips.com> In-Reply-To: <87y6fa9u3t.fsf@firetop.home> References: <87y6fa9u3t.fsf@firetop.home> From: "Fu, Chao-Ying" To: "Richard Sandiford" , "Maciej W. Rozycki" Cc: , "Garbacea, Ilie" , "Joseph Myers" , "Catherine Moore" , X-IsSubscribed: yes 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: 2010-05/txt/msg00299.txt.bz2 Richard Sandiford wrote: > > (mips_relax_frag): Handle microMIPS. >=20 > + gas_assert (fixp->fx_r_type =3D=3D BFD_RELOC_16_PCREL_S2 > + || fixp->fx_r_type =3D=3D BFD_RELOC_MICROMIPS_7_PCREL_S1 > + || fixp->fx_r_type =3D=3D BFD_RELOC_MICROMIPS_10_PCREL_S1 > + || fixp->fx_r_type =3D=3D BFD_RELOC_MICROMIPS_16_PCREL_S1); > + > + /* For 7/10 PCREL_S1, we just need to use=20 > fixp->fx_addnumber. */ > + if (fixp->fx_r_type =3D=3D BFD_RELOC_MICROMIPS_7_PCREL_S1 > + || fixp->fx_r_type =3D=3D BFD_RELOC_MICROMIPS_10_PCREL_S1) > + reloc->addend =3D fixp->fx_addnumber; > + else > + /* At this point, fx_addnumber is "symbol offset -=20 > pcrel address". > + Relocations want only the symbol offset. */ > + reloc->addend =3D fixp->fx_addnumber + reloc->address; >=20 > A better comment is needed. _Why_ do you just need fx_addnumber? >=20 Thanks for the review! The explanation is in another place as follows. Maybe we need to copy the comment to tc_gen_reloc from md_pcrel_from. Ex: long md_pcrel_from (fixS *fixP) { valueT addr =3D fixP->fx_where + fixP->fx_frag->fr_address; switch (fixP->fx_r_type) { /* We don't add addr, because it will cause the error checking of "addnumber" fail in write.c for *7/10_PCREL_S1. In tc_gen_reloc, we just use fixp->fx_addnumber. */ case BFD_RELOC_MICROMIPS_7_PCREL_S1: case BFD_RELOC_MICROMIPS_10_PCREL_S1: /* Return the beginning of the delay slot from the current insn. */ return 2; case BFD_RELOC_MICROMIPS_16_PCREL_S1: case BFD_RELOC_MICROMIPS_JMP: case BFD_RELOC_16_PCREL_S2: case BFD_RELOC_MIPS_JMP: /* Return the address of the delay slot. */ return addr + 4; ... The field of *7/10_PCREL_S1 is limited in the 16-bit instructions. If we add the "address", write.c will fail to check these two relocations due to overflow or something (I kind of forgot). From debugging, adding "address" is no use at all, because later "address" is subtracted. Maybe, we can do the same thing to *16_PCREL* by discarding address in tc_gen_reloc() and md_pcrel_from(), such that code looks cleaner and the same. Thanks! Regards, Chao-ying