gdbserver and gdb debugging stub for mips

gdbserver and gdb debugging stub for mips

[Wilson Chan]

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

RE: gdbserver and gdb debugging stub for mips

[朱凤]

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

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


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

RE: gdbserver and gdb debugging stub for mips

[朱凤]

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

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


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

Re: gdbserver and gdb debugging stub for mips

[Wolfgang Denk]

In message <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> you wrote:
> 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: wd@denx.de
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama

Re: gdbserver and gdb debugging stub for mips

[Daniel Jacobowitz]

On Fri, Aug 15, 2003 at 03:50:13PM +0200, Wolfgang Denk wrote:
> In message <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> you wrote:
> > 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).

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: gdbserver and gdb debugging stub for mips

[朱凤]

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

-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: 2003年8月15日 21:50
To: Öì·ï
Cc: Wilson Chan; linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips 


In message <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> you wrote:
> 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: wd@denx.de
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama

RE: gdbserver and gdb debugging stub for mips

[朱凤]

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

-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: 2003年8月15日 21:50
To: Öì·ï
Cc: Wilson Chan; linux-mips@linux-mips.org
Subject: Re: gdbserver and gdb debugging stub for mips 


In message <MGEELAPMEFMLFBMDBLKLGEKGCEAA.zhufeng@koretide.com.cn> you wrote:
> 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: wd@denx.de
"If you can, help others. If you can't, at least don't hurt  others."
- the Dalai Lama

Re: gdbserver and gdb debugging stub for mips

[Wolfgang Denk]

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

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

RE: gdbserver and gdb debugging stub for mips

[朱凤(zhufeng)]

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年8月15日 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

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

RE: gdbserver and gdb debugging stub for mips

[朱凤(zhufeng)]

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年8月15日 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

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

Re: gdbserver and gdb debugging stub for mips

[Fuxin Zhang]

[-- 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
>
>  
>

RE: gdbserver and gdb debugging stub for mips

[朱凤\(zhufeng\)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 4706 bytes --]

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: 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å¹?\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
>
>
>

RE: gdbserver and gdb debugging stub for mips

[朱凤\(zhufeng\)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 4706 bytes --]

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: 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å¹?\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
>
>
>

Re: gdbserver and gdb debugging stub for mips

[Fuxin Zhang]

[-- 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
>>
>>
>>
>>    
>>
>
>
>
>  
>