Subject: gdbserver and gdb debugging stub for mips

From: Wilson Chan <[email-masked]>
Date: Fri, 15 Aug 2003 18:24:12 +0800

Hi Sir:
   Does anybody has a gdbserver and gdb debugging stub for mips. I need
them to do remote debugging on mips. Thanks!

Wilson
08/15/2003

---

From: 朱凤 <[email-masked]>
Date: Fri, 15 Aug 2003 19:10:26 +0800

I'm also looking for them . If anybody who has , please tell me , thank you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Wilson Chan
Sent: 2003年8月15日 18:24
To: [email-masked]
Subject: gdbserver and gdb debugging stub for mips

Hi Sir:

Wilson
08/15/2003

---

From: Wolfgang Denk <[email-masked]>
Date: Fri, 15 Aug 2003 15:50:13 +0200

> I'm also looking for them . If anybody who has , please tell me , thank you.

MIPS isn't MIPS. What exactly are you looking for?

We have gdb (cross and native) / gdbserver included with our ELDK for
MIPS - this is for 4Kc CPUs.

See section "3. Embedded Linux Development Kit" at
http://www.denx.de/twiki/bin/view/DULG/BoardSelect (select incaip).

Hope this helps.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: [email-masked]
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama

---

From: Daniel Jacobowitz <[email-masked]>
Date: Fri, 15 Aug 2003 10:21:22 -0400

> http://www.denx.de/twiki/bin/view/DULG/BoardSelect (select incaip).

They're also, uh, distributed with the source of GDB.  Builds like any
other target application.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

---

From: 朱凤 <[email-masked]>
Date: Fri, 15 Aug 2003 22:49:21 +0800

what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many mips boards?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 2003年8月15日 21:50
To: Öì·ï
Cc: Wilson Chan; [email-masked]
Subject: Re: gdbserver and gdb debugging stub for mips 

Hope this helps.

Best regards,

Wolfgang Denk

---

From: Wolfgang Denk <[email-masked]>
Date: Fri, 15 Aug 2003 17:07:50 +0200

>  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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: [email-masked]
Newer disks don't have a rectangular layout anymore,  but  Unix  (and
SunOS) still assumes this.     - Peter Koch in <koch.779356598@rhein>

---

From: "朱凤\(zhufeng\)" <[email-masked]>
Date: Mon, 18 Aug 2003 09:16:06 +0800

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: [email-masked] [mailto:[email-masked]]
Sent: 2003年8月15日 23:08
To: Öì·ï
Cc: Wilson Chan; [email-masked]
Subject: Re: gdbserver and gdb debugging stub for mips 

Best regards,

Wolfgang Denk

---

From: Fuxin Zhang <[email-masked]>
Date: Mon, 18 Aug 2003 13:19:56 +0800

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:

>Sent: 2003幁��� 23:08

---

From: 朱凤\(zhufeng\) <[email-masked]>
Date: Thu, 21 Aug 2003 17:14:56 +0800

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
    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: [email-masked]
[mailto:[email-masked]]On Behalf Of Fuxin Zhang
Sent: 2003年8月18日 13:20
To: 朱凤(zhufeng)
Cc: [email-masked]
Subject: Re: gdbserver and gdb debugging stub for mips

    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

朱凤(zhufeng) wrote:

>when I build my mips program using gcc with -O0 , it is ok, while
using -o2, there come the following questions.
>Sent: 2003骞??棩 23:08
>To: 脰矛路茂

---

From: Fuxin Zhang <[email-masked]>
Date: Thu, 21 Aug 2003 17:43:28 +0800

>    uint tlb_D = 0 << 2;        //dirty bit
You want to write then you should set this bit, D means "writable",not 
really dirty

>>Sent: 2003骞????棩 23:08
>>In message <[email-masked]> you
>>    
>>
>wrote:
>  
>
>>    
>>
>>>what do you mean by "MIPS is NOT MIPS"? Does it mean there are too many
>>>      
>>>
>mips boards?
>  
>
>>>      
>>>