powerpc: fork && stepping (Was: [RFC, PATCH 0/14] utrace/ptrace)

Oleg Nesterov oleg at redhat.com
Thu Nov 26 21:04:58 UTC 2009


On 11/26, Oleg Nesterov wrote:
>
> Then it loops inside __GI__IO_list_lock
>
> 	0xfeacd24
> 	0xfeacd28
> 	0xfeacd2c
> 	0xfeacd30
> 	0xfeacd34
> 	...
>
> and so on forever,
>
> 	Dump of assembler code for function __GI__IO_list_lock:
> 	0x0feacce0 <__GI__IO_list_lock+0>:	mflr    r0
> 	0x0feacce4 <__GI__IO_list_lock+4>:	stwu    r1,-32(r1)
> 	0x0feacce8 <__GI__IO_list_lock+8>:	li      r11,0
> 	0x0feaccec <__GI__IO_list_lock+12>:	bcl-    20,4*cr7+so,0xfeaccf0 <__GI__IO_list_lock+16>
> 	0x0feaccf0 <__GI__IO_list_lock+16>:	li      r9,1
> 	0x0feaccf4 <__GI__IO_list_lock+20>:	stw     r0,36(r1)
> 	0x0feaccf8 <__GI__IO_list_lock+24>:	stw     r30,24(r1)
> 	0x0feaccfc <__GI__IO_list_lock+28>:	mflr    r30
> 	0x0feacd00 <__GI__IO_list_lock+32>:	stw     r31,28(r1)
> 	0x0feacd04 <__GI__IO_list_lock+36>:	stw     r29,20(r1)
> 	0x0feacd08 <__GI__IO_list_lock+40>:	addi    r29,r2,-29824
> 	0x0feacd0c <__GI__IO_list_lock+44>:	addis   r30,r30,16
> 	0x0feacd10 <__GI__IO_list_lock+48>:	addi    r30,r30,13060
> 	0x0feacd14 <__GI__IO_list_lock+52>:	lwz     r31,-6436(r30)
> 	0x0feacd18 <__GI__IO_list_lock+56>:	lwz     r0,8(r31)
> 	0x0feacd1c <__GI__IO_list_lock+60>:	cmpw    cr7,r0,r29
> 	0x0feacd20 <__GI__IO_list_lock+64>:	beq-    cr7,0xfeacd4c <__GI__IO_list_lock+108>
>
> beg->	0x0feacd24 <__GI__IO_list_lock+68>:	lwarx   r0,0,r31
> 	0x0feacd28 <__GI__IO_list_lock+72>:	cmpw    r0,r11
> 	0x0feacd2c <__GI__IO_list_lock+76>:	bne-    0xfeacd38 <__GI__IO_list_lock+88>
> 	0x0feacd30 <__GI__IO_list_lock+80>:	stwcx.  r9,0,r31
> end->	0x0feacd34 <__GI__IO_list_lock+84>:	bne+    0xfeacd24 <__GI__IO_list_lock+68>
>
> I don't even know whether this is user-space bug or kernel bug,
> the asm above is the black magic for me.

When I use gdb to step over __GI__IO_list_lock(), it doesn't loop.
I straced gdb and noticed that when the trace reaches

	0x0feacd24:	lwarx   r0,0,r31

gdb does PTRACE_CONT, not PTRACE_SINGLESTEP. After that the child
stops at 0x0feacd38, the next insn (isync).

> Anyone who knows something about powerpc can give me a hint?

Please ;)

Oleg.




More information about the utrace-devel mailing list