From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29525 invoked by alias); 22 Feb 2011 20:12:35 -0000 Received: (qmail 29508 invoked by uid 22791); 22 Feb 2011 20:12:33 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_EQ,TW_PX,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from dns1.mips.com (HELO dns1.mips.com) (12.201.5.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Feb 2011 20:12:21 +0000 Received: from exchdb01.mips.com (exchhub01.mips.com [192.168.36.84]) by dns1.mips.com (8.13.8/8.13.8) with ESMTP id p1MKCE1q026305; Tue, 22 Feb 2011 12:12:15 -0800 Received: from EXCHDB01.MIPS.com ([fe80::2897:a30d:a923:303]) by exchhub01.mips.com ([::1]) with mapi; Tue, 22 Feb 2011 12:12:12 -0800 From: "Fu, Chao-Ying" To: "Maciej W. Rozycki" , Richard Sandiford CC: "binutils@sourceware.org" , "Fuhler, Rich" , "Lau, David" , "Mills, Kevin" , "Garbacea, Ilie" , Catherine Moore , Nathan Sidwell , Joseph Myers , Nathan Froyd Subject: RE: [PATCH] MIPS: microMIPS ASE support Date: Tue, 22 Feb 2011 20:12:00 -0000 Message-ID: <7C6479EB2BF52547AC332FD6034646DA8495CBC4@exchdb01.mips.com> References: <87y6fa9u3t.fsf@firetop.home> <876302kqvu.fsf@firetop.home> <8739pb1qs5.fsf@firetop.home> In-Reply-To: x-ems-proccessed: 6LP3oGfGVdcdb8o1aBnt6w== x-ems-stamp: sGYCxvG1PyR8EySb6BzGPQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: 2011-02/txt/msg00277.txt.bz2 Maciej W. Rozycki wrote: >=20 > Chao-ying, there are a couple of questions for you=20 > throughout -- would=20 > you please give them a thought? And anyone, of course,=20 > please feel free=20 > to comment as you like. >=20 > > > +static char * > > > +micromips_label_name (void) > > > +{ > > > + char *p =3D micromips_target_name; > > > + char symbol_name_temporary[24]; > > > + unsigned long l; > > > + int i; > > > + > > > + if (*p) > > > + return p; > > > + > > > + i =3D 0; > > > + l =3D micromips_target_label; > > > +#ifdef LOCAL_LABEL_PREFIX > > > + *p++ =3D LOCAL_LABEL_PREFIX; > > > +#endif > > [...] > > > +int > > > +mips_label_is_local (const char *name) > > > +{ > > > + return strchr (name, MICROMIPS_LABEL_CHAR) !=3D NULL; > > > +} > >=20 > > Why is this change needed? The default local-label=20 > detection should be > > enough for ELF targets, which always have a LOCAL_LABEL_PREFIX. >=20 > I fail to see a justification, so I have removed this function.=20=20 > Chao-ying, do you have anything to add? I don't recall that I wrote this code. So, you may remove it. >=20 > > > + /* For microMIPS PC relative relocations, we cannot=20 > convert it to > > > + against a section. If we do, it will mess up the=20 > fixp->fx_offset. */ > > > if (fixp->fx_r_type =3D=3D BFD_RELOC_VTABLE_INHERIT > > > - || fixp->fx_r_type =3D=3D BFD_RELOC_VTABLE_ENTRY) > > > + || fixp->fx_r_type =3D=3D BFD_RELOC_VTABLE_ENTRY > > > + || 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) > >=20 > > "to be against a section". That's not a helpful comment though. > > _How_ will it mess up fixp->fx_offset? Give the reader a clue why > > the problem applies to BFD_RELOC_MICROMIPS_16_PCREL_S1 but not > > to something like BFD_RELOC_16_PCREL_S2. >=20 > I have failed to spot any problems with this hunk reverted=20 > and I'm not=20 > sure what I should be looking for. Therefore I feel a bit=20 > uneasy about=20 > removing it and only rephrased the comment without actually=20 > changing its=20 > meaning. Chao-ying, do you have anything to add? I added this code to avoid GAS errors when compiling Linux kernel for mic= roMIPS. Ex: mipsisa32r2-linux-gnu-gcc -Wp,-MD,kernel/.rtmutex.o.d -nostdinc -isystem= /hom e/fu/dev/binutils3/build-linux-20090506/tools/lib/gcc/mipsisa32r2-linux-gnu= /4.4. 0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -= Wunde f -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2 = -mabi =3D32 -G 0 -mno-abicalls -fno-pic -pipe -ffreestanding -EL -UMIPSEB -U_MIPS= EB -U__ MIPSEB -U__MIPSEB__ -UMIPSEL -U_MIPSEL -U__MIPSEL -U__MIPSEL__ -DMIPSEL -D_= MIPSE L -D__MIPSEL -D__MIPSEL__ -march=3Dmips32r2 -Wa,-mips32r2 -Wa,--trap -Iincl= ude/asm -mips/mach-sim -Iinclude/asm-mips/mach-generic -mmicromips -fomit-frame-poi= nter -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -m= micro mips -D"KBUILD_STR(s)=3D#s" -D"KBUILD_BASENAME=3DKBUILD_STR(rtmutex)" -= D"KBUILD_ MODNAME=3DKBUILD_STR(rtmutex)" -c -o kernel/.tmp_rtmutex.o kernel/rtmutex.c {standard input}: Assembler messages: {standard input}:3030: Error: relocation overflow {standard input}:3125: Error: relocation overflow {standard input}:3213: Error: relocation overflow {standard input}:3408: Error: relocation overflow make[1]: *** [kernel/rtmutex.o] Error 1 A simple case is as follows. <597> # cat 2.s .set push .set noat .set mips3 .space 1<<10 1: ll $6, 0($2) # __cmpxchg_u32 bne $6, $0, 2f .set mips0 move $1, $3 .set mips3 sc $1, 0($2) beqz $1, 3f 2: .subsection 2 3: b 1b .previous .set pop I kind of forgot my debug process to come out with the solution. Maybe if we use the section as the target, R_MICROMIPS_PC7_S1 will lead to incorrect checking for overflow. Ex: (write.c) static void adjust_reloc_syms (bfd *abfd ATTRIBUTE_UNUSED, asection *sec, void *xxx ATTRIBUTE_UNUSED) { segment_info_type *seginfo =3D seg_info (sec); fixS *fixp; ... /* We refetch the segment when calling section_symbol, rather than using symsec, because S_GET_VALUE may wind up changing the section when it calls resolve_symbol_value. */ fixp->fx_offset +=3D S_GET_VALUE (sym); <----- THIS WILL BE TOO BIG= , if we use the section. fixp->fx_addsy =3D section_symbol (S_GET_SEGMENT (sym)); #ifdef DEBUG5 fprintf (stderr, "\nadjusted fixup:\n"); print_fixup (fixp); #endif } dump_section_relocs (abfd, sec, stderr); } Thanks! Regards, Chao-ying