This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: Link error: relocation truncated to fit: R_MIPS_GPREL16 time
- Subject: Re: [ECOS] Link error: relocation truncated to fit: R_MIPS_GPREL16 time
- From: "Rosimildo daSilva" <rosimildo at hotmail dot com>
- Date: Mon, 17 Apr 2000 13:40:15 CDT
- Cc: ecos-discuss at sourceware dot cygnus dot com
>From: Bart Veer <bartv@redhat.com>
>Reply-To: bartv@redhat.com
>To: rosimildo@hotmail.com
>CC: ecos-discuss@sourceware.cygnus.com
>Subject: Re: [ECOS] Link error: relocation truncated to fit: R_MIPS_GPREL16
>time
>Date: Mon, 17 Apr 2000 13:55:54 +0100
>
> >>>>> "Rosimildo" == Rosimildo daSilva <rosimildo@hotmail.com> writes:
>
> <snip>
>
> Rosimildo> /ecos/work/install/lib/libtarget.a(net_tcpip_ip_id.o): In
>function
> Rosimildo> `ip_initid':
> Rosimildo>
>/ecos/ecos-1.3.1/packages/net/tcpip/v1_0b1/src/sys/netinet/ip_id.c:231:
> Rosimildo> relocaton truncated to fit: R_MIPS_GPREL16 time
>
> Rosimildo> I am wondering if this seems familiar to anyone doing
> Rosimildo> MIPS stuff.
>
Bart,
Thanks for you very complete explanation. I saw similar
recommendations from the gcc mail-list, expect that they
recommended -G0 in a few occasions.
>I think I know what the problem is, but I cannot be 100% sure.
>
>The MIPS architecture allows for a certain amount of global data to be
>accessed more quickly than others, using different instructions. The
>compiler exploits this facility by putting small global variables into
>sections .sdata and .sbss, rather than the normal sections .data and
>.bss. Of course the compiler has no idea how many modules are going to
>end up in the final executable. Hence at link-time it is possible that
>there is now too much data in these sections, and you will get a
>"relocation truncated" message. For most applications you will not hit
>the limit, in fact I am somewhat surprised that any ordinary eCos
>application would cause the problem to arise.
I guess I have found the problem. I do not understand it yet.
After trying many things, I discovered that if the application code uses the
function call "time()", and it gets linked in, it does
trigger the problem.
The problem seems to be that the TCP/IP stack has a global
variable called "time". I could not find where it is instantiated.
So, I added it to ? src/ecos/support.c.
It did not solve the problem, got the same error.
Next thing I did was to replace the global variable "time" to
"k_time". It does work if I do that.
Now I am totally puzzled. GCC should be able to
detect that one time is code, and the other one is data.
Also, this has worked to all other platforms.
I have this workaround, but I still not understand it.
Rosimildo.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com