[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Dec 2013 02:57:30 +0100
From: John Spencer <maillist-musl@...fooze.de>
To: musl@...ts.openwall.com
Subject: Re: mistake in powerpc clone.s?
James Gregurich wrote:
> hi,
>
> I was tracking down some odd behavior in the debugger that makes it at least appear as if a stack corruption has occurred. I followed it to clone.s.
>
>
>
> could the following be a mistake? Notice that r30 is stored to $r1 - 16 while it is restored to $r1 + 0. When I step through this code in the debugger, once 'stwu 30, -16(1)’ is executed gdb claims the stack is corrupted…and this corruption persists up into my project code. I suspect the -16 should be a 0. Comments?
>
>
>
>
>
> # store non-volatile regs r30, r31 on stack in order to put our
> # start func and its arg there
> stwu 30, -16(1)
stwu first updates r1 to r1 - 16, then stores into that address
this is equivalent to
subi 1,1,16
stw 30, 0(1)
the weird behaviour in gdb you're experiencing is probably because of
the reentrant nature of the clone syscall.
there may still be bugs tho, but at least the pthread tests of the
libc-testsuite worked correctly on ppc. however this arch was otherwise
not widely tested so far (a full sabotage build a year ago was the
biggest test so far).
what is the exact problem you're trying to fix ?
> stw 31, 4(1)
>
> ...
>
> # restore stack
> lwz 30, 0(1)
> lwz 31, 4(1)
> addi 1, 1, 16
>
> blr
>
>
>
>
> gdb log:
>
>
>
>
> (gdb) bt
> #0 0x01922e14 in clone ()
> #1 0x0191d364 in __posix_spawnx (
> res=<unknown type in /root/test/SuperNodeDmx.elf.debug, CU 0x128482, DIE 0x1284b9>,
> path=<unknown type in /root/test/SuperNodeDmx.elf.debug, CU 0x128482, DIE 0x1284c8>, exec=0x1926b30 <execve>, fa
> attr=<unknown type in /root/test/SuperNodeDmx.elf.debug, CU 0x128482, DIE 0x1284f5>, argv=0xbffff7e8, envp=0xbff6
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb) disass
> Dump of assembler code for function clone:
> 0x01922e10 <+0>: stwu r30,-16(r1)
> => 0x01922e14 <+4>: stw r31,4(r1)
> 0x01922e18 <+8>: mr r30,r3
> 0x01922e1c <+12>: mr r31,r6
> 0x01922e20 <+16>: mr r3,r5
> 0x01922e24 <+20>: mr r5,r7
> 0x01922e28 <+24>: mr r6,r8
> 0x01922e2c <+28>: mr r7,r9
> 0x01922e30 <+32>: li r0,120
> 0x01922e34 <+36>: sc
> 0x01922e38 <+40>: bns+ 0x1922e40 <clone+48>
> 0x01922e3c <+44>: neg r3,r3
> 0x01922e40 <+48>: cmpwi cr7,r3,0
> 0x01922e44 <+52>: bne- cr7,0x1922e5c <clone+76>
> 0x01922e48 <+56>: mr r3,r31
> 0x01922e4c <+60>: mtctr r30
> 0x01922e50 <+64>: bctrl
> 0x01922e54 <+68>: li r0,1
> 0x01922e58 <+72>: sc
> 0x01922e5c <+76>: lwz r30,0(r1)
> 0x01922e60 <+80>: lwz r31,4(r1)
> 0x01922e64 <+84>: addi r1,r1,16
> 0x01922e68 <+88>: blr
> End of assembler dump.
>
>
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
