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
- To: rosimildo at hotmail dot com, gthomas at redhat dot com
- Subject: Re: [ECOS] Link error: relocation truncated to fit: R_MIPS_GPREL16 time
- From: Bart Veer <bartv at redhat dot com>
- Date: Tue, 18 Apr 2000 15:44:05 +0100
- CC: ecos-discuss at sourceware dot cygnus dot com
- References: <20000417184015.51360.qmail@hotmail.com>
- Reply-to: bartv at redhat dot com
>>>>> "Rosimildo" == Rosimildo daSilva <rosimildo@hotmail.com> writes:
<snip>
Rosimildo> I guess I have found the problem. I do not understand
Rosimildo> it yet.
Rosimildo> After trying many things, I discovered that if the
Rosimildo> application code uses the function call "time()", and
Rosimildo> it gets linked in, it does trigger the problem.
Rosimildo> The problem seems to be that the TCP/IP stack has a
Rosimildo> global variable called "time". I could not find where
Rosimildo> it is instantiated. So, I added it to ?
Rosimildo> src/ecos/support.c. It did not solve the problem, got
Rosimildo> the same error.
Rosimildo> Next thing I did was to replace the global variable
Rosimildo> "time" to "k_time". It does work if I do that.
Rosimildo> Now I am totally puzzled. GCC should be able to detect
Rosimildo> that one time is code, and the other one is data. Also,
Rosimildo> this has worked to all other platforms.
Rosimildo> I have this workaround, but I still not understand it.
I am not a C language lawyer, but I suspect that having both a global
variable and a function with the same name is disallowed. Consider
code such as:
void* x = (void*) &time;
Should x be given the address of the "time" function or the "time"
variable? I suspect that what is happening is that the compiler has
generated a reference to a variable "time" in the .sdata section, and
the linker is trying to bind it to the function "time" in another
section, thus explaining the particular message you saw. Possibly the
linker could resolve this better, and it really should give a better
diagnostic if the duplicate definition is the real problem, but I have
not yet delved into libbfd and the linker internals so I would not
know how to go about fixing that.
In the context of the BSD kernel, having a global variable "time" is
not a problem because the function "time" is in the C library and the
kernel is not linked with that library. In eCos we do not have that
separation.
Gary (and other interested parties), could you have a look at the
TCP/IP stack and see what it is going on here? We may need to think
about namespace pollution in the stack generally.
Bart Veer // eCos net maintainer