[Top] [All Lists]

RE: gdbserver and gdb debugging stub for mips

To: "Fuxin Zhang" <>
Subject: RE: gdbserver and gdb debugging stub for mips
From: 朱凤\(zhufeng\) <>
Date: Thu, 21 Aug 2003 17:14:56 +0800
Cc: <>
Importance: Normal
In-reply-to: <>
Original-recipient: rfc822;
I wanto access 0x40000000 on mips, I did the following,but still exception

     page MASK is set to 4k

    uint asid = 0;
    ulong reg_entryhi = 0x40000000 | asid;

    ulong reg_entrylo0;
    ulong phyadd0  = 0x20000000 >> 12;
    ulong pfn0 = phyadd0 << 6;
    uint tlb_C = 2 << 3;     //cache coherence bit
    uint tlb_D = 0 << 2;        //dirty bit
    uint tlb_V = 1 << 1;        // valid bit
    uint tlb_G = 1;             //global bit

    reg_entrylo0 = pfn0|tlb_C|tlb_D|tlb_V|tlb_G;

    *((unsigned long *)0x40000000) = 0x44;  //still trap into exception

what's the problem? thanks

-----Original Message-----
[]On Behalf Of Fuxin Zhang
Sent: 2003年8月18日 13:20
To: 朱凤(zhufeng)
Subject: Re: gdbserver and gdb debugging stub for mips

An answer cited from elsewhere:

    Rosimildo> /ecos/work/install/lib/libtarget.a(net_tcpip_ip_id.o): In
    Rosimildo> `ip_initid':
    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

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

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.
>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: []
>Sent: 2003骞???? 23:08
>To: ??矛路茂
>Cc: Wilson Chan;
>Subject: Re: gdbserver and gdb debugging stub for mips
>In message <> you
>> 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

<Prev in Thread] Current Thread [Next in Thread>