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: 5046 bytes --]



Öì·ï(zhufeng) wrote:

>I 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
>  
>
You want to write then you should set this bit, D means "writable",not 
really dirty

>    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, 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å¹????—¥ 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
>>
>>
>>
>>    
>>
>
>
>
>  
>