Re: gdbserver and gdb debugging stub for mips

[Fuxin Zhang <fxzhang@ict.ac.cn>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030; format=flowed, Size: 3748 bytes --]

An answer cited from elsewhere:
-----
    <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.

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.

The correct solution would be for the linker to handle this situation
and decide which global variables should remain in the special region
and which ones should be moved elsewhere. In theory it could use
information such as the number of accesses to a particular global, or
maybe even profiling feedback, to decide which variables are most
worthwhile keeping in the special region. Unfortunately this would
require the linker changing the instructions used to access the
variables that are moved to the ordinary .data and .bss sections,
which is a non-trivial operation. Also, having the linker change
instructions would mess up other things such as the compiler's
attempts at instruction scheduling.

On occasion we have had requests to fix the toolchain so that it does
the right thing (for some definition of the right thing), but the work
is sufficiently involved that so far nobody has been willing to fund
it.

There is a workaround. The mips toolchain accepts an argument -G<num>,
with a default value of 8. This means that any global variable <= 8
bytes will end up in .sdata or .sbss. If you compile all the code with
a different value, e.g. -G4, then less data ends up in the special
sections so you will not hit the overflow condition. There is a
performance penalty, of course. I suggest experimenting with -G
values, and looking at the relevant gcc documentation as well since
things may have changed since the last time I looked at this. It might
also be worthwhile searching through the gcc mailing list archives at
http://gcc.gnu.org/ml/gcc/

Bart Veer // eCos net maintainer



Öì·ï(zhufeng) wrote:

>when I build my mips program using gcc with -O0 , it is ok, while using -o2, there come the following questions.
>lingking,,,
>
>relocation truncated to fit: R_MIPS_GPREL16  __global_ctor_start
>relocation truncated to fit: R_MIPS_GPREL16 __global_ctor_end
>relocation truncated to fit: R_MIPS_GPREL16 _recycle_start 
>
>and so on.
>
>Has anybody encounter such questions?
>
>
>
>-----Original Message-----
>From: wd@denx.de [mailto:wd@denx.de]
>Sent: 2003幁\x7f\x7f\x7f\x7f—¥ 23:08
>To: Öì·ï
>Cc: Wilson Chan; linux-mips@linux-mips.org
>Subject: Re: gdbserver and gdb debugging stub for mips 
>
>
>In message <MGEELAPMEFMLFBMDBLKLIEKICEAA.zhufeng@koretide.com.cn> you wrote:
>  
>
>> what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many mips boards?
>>    
>>
>
>big endian, little endian, 32 bit, 64 bit, ...
>
>It means that there are several  different  configurations,  and  you
>must use tools to match your configuration.
>
>Best regards,
>
>Wolfgang Denk
>
>  
>