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]

RE: Error message of mips cross compiler



>-----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]