Öì·ï(zhufeng) wrote:
You want to write then you should set this bit, D means "writable",not really dirtyI wanto access 0x40000000 on mips, I did the following,but still exception happed:
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; set_entryhi(reg_entryhi); set_entrylo0(reg_entrylo0); set_entrylo1(0|tlb_G); tlb_write_indexed();
*((unsigned long *)0x40000000) = 0x44; //still trap into exception
what's the problem? thanks
-----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Fuxin Zhang Sent: 2003Äê8ÔÂ18ÈÕ 13:20 To: Öì·ï(zhufeng) Cc: linux-mips@linux-mips.org Subject: Re: gdbserver and gdb debugging stub for mips
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, whileusing -o2, there come the following questions.
lingking,,,wrote:
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å¹????—¥ 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
mips boards?
what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many
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
