This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>-----Original Message----- >From: SeanChang [mailto:seanchang@mail.arti.com.tw] >Sent: 19 July 2001 05:00 >David > I have changed my outlook seeting to send text formatted mail. Here's the reply I promised! >Unfortunately,Adding -mlong-calls doesn't solve my problem. >I found all error occured when some C codes access external global >variables(located in .data). >Why? Oh!! I really thought that would fix it. Let me explain: >> I got a error message when linking our objects,'relocation trunvated to >> fit: R_MIPS_GPREL16 DeviceName' This error is very similar to a linker error we see on ppc very often, when the target of a branch is too far away in memory for the +-32 Mb displacement available from a branch instruction. The relocation cannot be done by the linker because the offset value won't fit into the bitfield in the opcode where it should be placed. The error you have must be very similar; the '16' at the end means that the field in question is 16 bits wide, and so we can see that the linker must be trying to put a displacement > +-32768 in there. GPREL indicates that this is some kind of relative addressing scheme. So what must be happening is that some of your variables in .data are located too far away from the code in .code that wishes to access them with a 16-bit offset. I assumed it was a branch that produced the problem, but as you have shown it isn't. Take a look at this part of the Gcc manual (Invoking GCC/Submodel options/ MIPS options) `-mgpopt' `-mno-gpopt' The `-mgpopt' switch says to write all of the data declarations before the instructions in the text section, this allows the MIPS assembler to generate one word memory references instead of using two words for short global or static data items. This is on by default if optimization is selected. Are you using this option, or is it on by default because you have optimization turned on? It seems that this option could be causing the assembler to generate "one word memory references", which I assume is the 16-bit relocation type that is failing. Try turning the option off and see if that helps. DaveK -- "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." - Kristian Wilson, Nintendo, Inc, 1989. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |