[ECOS] mips: address error after break

[ECOS] mips: address error after break

[Motoya Kurotsu]

Hi,
I'm porting ecos on the customed mips base board with NKK's NR4700 
(maybe, compatible with IDT's R4700) as CPU and Gelileo Technology's 
GT-64010 as controller, based on VR4373 ports. Stub seems to 
work with gdb except one problem. That is, after I stop the program 
at a breakpoint and continue it, the address error exception occurs. 
Checking the BadVAddr register, the address which caused exception 
seems to be correctly aligned. Moreover, the occurence of exception 
seems to depend on where the breakpoint is placed. Could anyone 
suggest me anything?

Regards,
Motoya Kurotsu
Alilled Telesis K.K.
--------------------
I'm using the codes and tools in the following:
ecos:	 snapshot of Jan 25, 2001
binutils: 2.10.1
gcc	: 2.95.2.1, compiled with mips64orion-idt-elf as the prefix	
gdb	: insight-5.0

Below is the process of regenerating problem and the result:
(gdb) b led.c:act_blink
Breakpoint 1 at 0x80101174: file led.c, line 26.
(gdb) c
Continuing.

Breakpoint 1, act_blink () at led.c:26
26              for(j=0;j<10;j++) {
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x80101178 in act_blink () at led.c:26
26              for(j=0;j<10;j++) {
(gdb) info registers
	............         
                    gp               sp               s8               ra
 R28  ffffffff8012a410 ffffffff8012b530 ffffffff8012b530 ffffffff8010112c 
                    sr               lo               hi              bad
              34001802 0000000000040000 000000000eac8849 ffffffff8012b544 
                 cause               pc
      0000000000008014 ffffffff80101178 
	............
(gdb) disassemble 
Dump of assembler code for function act_blink:
0x80101164 <act_blink>: addiu   $sp,$sp,-32
0x80101168 <act_blink+4>:       sw      $ra,28($sp)
0x8010116c <act_blink+8>:       sw      $s8,24($sp)
0x80101170 <act_blink+12>:      move    $s8,$sp
0x80101174 <act_blink+16>:      nop
0x80101178 <act_blink+20>:      sw      $zero,20($s8)
0x8010117c <act_blink+24>:      lw      $v0,20($s8)
0x80101180 <act_blink+28>:      slti    $v1,$v0,10
	............

Below is the case where exception doesn't happen:
(gdb) delete 1
(gdb) break led.c:19
Breakpoint 2 at 0x80101124: file led.c, line 19.
(gdb) j _start
Line 106 is not in `act_blink'.  Jump anyway? (y or n) y

Continuing at 0x801000f0.

Breakpoint 2, cyg_user_start () at led.c:19
19                      act_blink(); 
(gdb) c
Continuing.

Breakpoint 2, cyg_user_start () at led.c:19
19                      act_blink(); 
(gdb) c
Continuing.

Breakpoint 2, cyg_user_start () at led.c:19
19                      act_blink(); 
(gdb) disassemble 
Dump of assembler code for function act_blink:
0x801010f4 <cyg_user_start>:    addiu   $sp,$sp,-32
0x801010f8 <cyg_user_start+4>:  sw      $ra,28($sp)
0x801010fc <cyg_user_start+8>:  sw      $s8,24($sp)
0x80101100 <cyg_user_start+12>: move    $s8,$sp
0x80101104 <cyg_user_start+16>: nop
0x80101108 <cyg_user_start+20>: sw      $zero,16($s8)
0x8010110c <cyg_user_start+24>: lw      $v0,16($s8)
0x80101110 <cyg_user_start+28>: slti    $v1,$v0,1000
0x80101114 <cyg_user_start+32>: bnez    $v1,0x80101124 <cyg_user_start+48>
0x80101118 <cyg_user_start+36>: nop
0x8010111c <cyg_user_start+40>: j       0x80101140 <cyg_user_start+76>
0x80101120 <cyg_user_start+44>: nop
0x80101124 <cyg_user_start+48>: jal     0x80101164 <act_blink>
0x80101128 <cyg_user_start+52>: nop
0x8010112c <cyg_user_start+56>: lw      $v0,16($s8)
0x80101130 <cyg_user_start+60>: addiu   $v1,$v0,1
0x80101134 <cyg_user_start+64>: sw      $v1,16($s8)
0x80101138 <cyg_user_start+68>: j       0x8010110c <cyg_user_start+24>
0x8010113c <cyg_user_start+72>: nop
	............

My sample program:

13 void act_blink(void);
14 int cyg_user_start(void)
15 {
16	int i;
17
18	for(i=0;i<1000;i++) {
19		act_blink(); 
20	}
21  return 0;
22 }
23 void act_blink(void)
24 {
25	int i,j;
26	for(j=0;j<10;j++) {
27		for (i=0; i<100000; i++)
28			hal_led_act();
29		for (i=0; i<100000; i++)
30			hal_led_on(0,0);
31	}
32 }

I compiled the stub and my program without -ffunction-sections, 
-fdata-sections as CFLAGS and --gc-sections as LDFLAGS so that 
the breakpoint works correctly.
===========

Re: [ECOS] mips: address error after break

[Jonathan Larmour]

Motoya Kurotsu wrote:
> 
> Hi,
> I'm porting ecos on the customed mips base board with NKK's NR4700
> (maybe, compatible with IDT's R4700) as CPU and Gelileo Technology's
> GT-64010 as controller, based on VR4373 ports. Stub seems to
> work with gdb except one problem. That is, after I stop the program
> at a breakpoint and continue it, the address error exception occurs.
> Checking the BadVAddr register, the address which caused exception
> seems to be correctly aligned. Moreover, the occurence of exception
> seems to depend on where the breakpoint is placed. Could anyone
> suggest me anything?

When restarting after a breakpoint, the target gets stepped one instruction
before really being continued. Perhaps your CPU has opcodes or opcode
formats not covered by __single_step() in
hal/mips/arch/VERSION/src/mips-stub.c?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] mips: address error after break

[Motoya Kurotsu]

> When restarting after a breakpoint, the target gets stepped one instruction
> before really being continued. Perhaps your CPU has opcodes or opcode
> formats not covered by __single_step() in
> hal/mips/arch/VERSION/src/mips-stub.c?
> 
> Jifl
> -- 

Thanks, Jonathan.

I finally found the cause of this problem. The immediate cause is that 
the upper 32 bits of general registers are made zero during copying 
registers[] to HAL_SavedRegisters since target_register_t was still 
unsigned long. On the other side, general registers were handled by double 
word store and load in vectors.S. Thus the upper 32 bits of general registers 
were all zero at the restoration from exception. Since the latest code 
seems to support 64bit mode, this problem may not occur.

Motoya Kurotsu
Allied Telesis K.K.