[#4051] single stepping userspace sometimes hangs the system

Submitted By: Mike Frysinger

Open Date

2008-04-23 00:58:33 Close Date

2008-05-20 19:09:11

Priority:

Medium Assignee:

Jie Zhang

Status:

Closed Fixed In Release:

N/A

Found In Release:

N/A Release:

svn trunk 4651

Category:

N/A Board:

N/A

Processor:

N/A Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Fixed

Uboot version or rev.:

Toolchain version or rev.:

App binary format:

N/A

Summary: single stepping userspace sometimes hangs the system

Details:

before the recent trap updates, when single stepping through the fixed code section, we'd randomly (but quite frequently) get the "Undefined instruction" trap below ... but things would continue to run in userspace without a problem (in other words, the application that was being debugged would not get killed and things appeared to still work properly; kind of odd). with current svn trunk though, the kernel just hangs and then the watchdog kicks it.

Undefined instruction

- May be used to emulate instructions that are not defined for

a particular processor implementation.

Deferred Exception context

CURRENT PROCESS:

COMM=a.out PID=143

TEXT = 0x00a59000-0x00a5975c DATA = 0x00a5675c-0x00a568bc

BSS = 0x00a568bc-0x00a20000 USER-STACK = 0x00a3fed0

return address: [0xffa00612]; contents of:

0xffa005f0: 017e 0179 0140 0140 6000 3620 3628 3630

0xffa00600: 3638 3046 6fa6 e330 1f95 6c66 2000 0000

0xffa00610: 017a [0148] 0140 05c0 014f 0178 0150 0151

0xffa00620: 0152 0153 0154 0155 0156 0157 015c 015d

SEQUENCER STATUS: Not tainted

SEQSTAT: 00062021 IPEND: 0030 SYSCFG: 0007

HWERRCAUSE: 0x18

EXCAUSE : 0x21

RETE: <0x00000000> /* Maybe null pointer? */

RETN: <0x00a1bffc> /* unknown address */

RETX: <0xffa00612> { _exception_to_level5 + 0x2 }

RETS: <0x0062a7b6> [ /lib/libuClibc-0.9.29.so + 0x2a7b6 ]

PC : <0x0314216e> [ /lib/libgcc_s.so.1 + 0x216e ]

DCPLB_FAULT_ADDR: <0x0015f16c> /* unknown address */

ICPLB_FAULT_ADDR: <0xffa00612> { _exception_to_level5 + 0x2 }

PROCESSOR STATE:

R0 : fffffe00 R1 : 00000001 R2 : 00000000 R3 : 00000000

R4 : 00a5942c R5 : 00a3ff80 R6 : 00a59730 R7 : 00401808

P0 : 00000020 P1 : 03142164 P2 : 00400e0c P3 : 0316f300

P4 : 00a59428 P5 : 00a55298 FP : 00a3fd9c SP : 00a1bf24

LB0: 03142179 LT0: 0314216c LC0: 00000018

LB1: 03504569 LT1: 0350453a LC1: 00000001

B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 00a3ff58

B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 00a59758

B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 0350713c

B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000

A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000

USP : 00a3fd88 ASTAT: 02003025

Hardware Trace:

Stack from 00a1bf04:

0316f300 ffa006c8 0015f184 0015f184 0015f17c 7fffffff 00a5942c 03142170

ffa00612 00000030 00062021 00000000 00a1bffc ffa00612 0314216e 0062a7b6

fffffe00 02003025 03504569 03142179 0350453a 0314216c 00000001 00000018

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 0350713c 00a59758 00a3ff58 00a3fd88 00a3fd9c 00a55298 00a59428

Call Trace:

note that single stepping the fixed code section seems to make the error happen much more frequently, but if i put gdb into single stepping normal code, i can eventually get it to die.

the way to reproduce is to make an app with an infinite loop like so:

int main() { asm volatile("jump.s 0;"); }

and then connect to it with gdb and just do:

define f

stepi

end

...

for the faster method, you can call the CAS32 fixed code:

int main()

{

int i = 0;

__asm__ __volatile__ (

"1:"

"R0 = 1;"

"[%0] = R0;"

"R1 = 1;"

"R2 = 0;"

"P0.l = 0x420;"

"P0.h = 0;"

"call (P0);"

"jump 1b;"

: "a"(&i)

);

return 0;

}

put a watchpoint on &i, and have gdb automatically continue when the watchpoint is hit:

$ bfin-uclinux-gdb ./a.out.gdb

_stext () at libc/sysdeps/linux/bfin/crt1.S:84

84 FP = 0;

Current language: auto; currently asm

(gdb) b main

Breakpoint 1 at 0x3780140: file cas.c, line 3.

(gdb) c

Continuing.

Breakpoint 1, main () at cas.c:3

3 int i = 0;

Current language: auto; currently c

(gdb) print &i

$1 = (int *) 0x3781f30

(gdb) watch *(int *)0x3781f30

Watchpoint 2: *(int *) 0x3781f30

(gdb) commands 2

Type commands for when breakpoint 2 is hit, one per line.

End with a line saying just "end".

>bt 2

>end

(gdb) c

Continuing.

Watchpoint 2: *(int *) 0x3781f30

Old value = 0x3780292

New value = 0x0

main () at cas.c:4

4 __asm__ __volatile__ (

#0 main () at cas.c:4

Watchpoint 2: *(int *) 0x3781f30

Old value = 0x0

New value = 0x1

0x0378014c in main () at cas.c:4

4 __asm__ __volatile__ (

#0 0x0378014c in main () at cas.c:4

Follow-ups

--- Mike Frysinger 2008-05-20 19:09:11

Bernd fixed this some time ago when he was banging on the traps code

Files

Changes

Commits

Dependencies

Duplicates

Associations