* mistake in powerpc clone.s?
@ 2013-12-26 22:08 James Gregurich
2013-12-27 1:57 ` John Spencer
0 siblings, 1 reply; 6+ messages in thread
From: James Gregurich @ 2013-12-26 22:08 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
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)
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.
[-- Attachment #2: Type: text/html, Size: 7966 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: mistake in powerpc clone.s?
2013-12-26 22:08 mistake in powerpc clone.s? James Gregurich
@ 2013-12-27 1:57 ` John Spencer
2013-12-27 3:13 ` James Gregurich
0 siblings, 1 reply; 6+ messages in thread
From: John Spencer @ 2013-12-27 1:57 UTC (permalink / raw)
To: musl
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.
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mistake in powerpc clone.s?
2013-12-27 1:57 ` John Spencer
@ 2013-12-27 3:13 ` James Gregurich
2013-12-27 3:42 ` Rich Felker
0 siblings, 1 reply; 6+ messages in thread
From: James Gregurich @ 2013-12-27 3:13 UTC (permalink / raw)
To: musl
When I debug my app in gdb, I consistently get “Backtrace stopped: previous frame inner to this frame (corrupt stack?)” at the lower end of the backtrace. I set break points at each function in the back trace and that message persists up to the __clone() invocation. until that line that I pointed out, the backtrace is normal. Once that instruction is executed, the backtrace is permanently broken for that thread.
I’m not educated enough at that level of operation to know what is wrong (yet), but something is wrong there.
If someone would like to experiment with some changes, I can do that.
-James
On Dec 26, 2013, at 7:57 PM, John Spencer <maillist-musl@barfooze.de> wrote:
> what is the exact problem you're trying to fix ?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mistake in powerpc clone.s?
2013-12-27 3:13 ` James Gregurich
@ 2013-12-27 3:42 ` Rich Felker
2013-12-27 3:45 ` James Gregurich
0 siblings, 1 reply; 6+ messages in thread
From: Rich Felker @ 2013-12-27 3:42 UTC (permalink / raw)
To: musl
On Thu, Dec 26, 2013 at 09:13:59PM -0600, James Gregurich wrote:
>
>
> When I debug my app in gdb, I consistently get “Backtrace stopped:
> previous frame inner to this frame (corrupt stack?)” at the lower
> end of the backtrace. I set break points at each function in the
> back trace and that message persists up to the __clone() invocation.
> until that line that I pointed out, the backtrace is normal. Once
> that instruction is executed, the backtrace is permanently broken
> for that thread.
In the backtrace for a thread other than the main thread, it's normal
and expected for the backtrace to end at __clone; it's where the
thread started. The "corrupt stack" message is unwanted (musl should
be arranging for the frame pointer to be zero so that debuggers
recognize that there's nothing else on the stack, and maybe this needs
fixing) but I don't think it's necessarily indicative of any bug.
Rich
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mistake in powerpc clone.s?
2013-12-27 3:42 ` Rich Felker
@ 2013-12-27 3:45 ` James Gregurich
2013-12-27 22:34 ` James Gregurich
0 siblings, 1 reply; 6+ messages in thread
From: James Gregurich @ 2013-12-27 3:45 UTC (permalink / raw)
To: musl
If you want me to try a patch, let me know.
BTW: I have an actual crash in my app that appears to be a stack corruption. I was following up on that message to see if it was relevant to the crash.
-James
On Dec 26, 2013, at 9:42 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Thu, Dec 26, 2013 at 09:13:59PM -0600, James Gregurich wrote:
>>
>>
>> When I debug my app in gdb, I consistently get “Backtrace stopped:
>> previous frame inner to this frame (corrupt stack?)” at the lower
>> end of the backtrace. I set break points at each function in the
>> back trace and that message persists up to the __clone() invocation.
>> until that line that I pointed out, the backtrace is normal. Once
>> that instruction is executed, the backtrace is permanently broken
>> for that thread.
>
> In the backtrace for a thread other than the main thread, it's normal
> and expected for the backtrace to end at __clone; it's where the
> thread started. The "corrupt stack" message is unwanted (musl should
> be arranging for the frame pointer to be zero so that debuggers
> recognize that there's nothing else on the stack, and maybe this needs
> fixing) but I don't think it's necessarily indicative of any bug.
>
> Rich
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: mistake in powerpc clone.s?
2013-12-27 3:45 ` James Gregurich
@ 2013-12-27 22:34 ` James Gregurich
0 siblings, 0 replies; 6+ messages in thread
From: James Gregurich @ 2013-12-27 22:34 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]
a followup…
GDB log example. this is what one typically sees. I edited out the private source code info. A message like that can easily send one chasing wild geese when he is hunting for a fault.
(gdb) bt
#0 c::f (this=0x0, dmxData=0x19cea20 "")
at <source location>
#1 0x0182e5e0 in c::f (this=0x1a1e860,
enabledPorts=0x48015cb8)
at <source location>
#2 0x0182e4c0 in c::f (this=<optimized out>)
at <source location>
#3 0x0181fdd8 in c::f (this=<optimized out>)
at <source location>
#4 0x0181faf4 in c::f (arg=0x1a1e860)
at <source location>
#5 0x0190ff20 in start (p=0x48015d40) at src/thread/pthread_create.c:104
#6 0x01922e54 in clone ()
Backtrace stopped: frame did not save the PC
(gdb)
On Dec 26, 2013, at 9:45 PM, James Gregurich <bayoubengal@mac.com> wrote:
> If you want me to try a patch, let me know.
>
> BTW: I have an actual crash in my app that appears to be a stack corruption. I was following up on that message to see if it was relevant to the crash.
>
> -James
>
>
> On Dec 26, 2013, at 9:42 PM, Rich Felker <dalias@aerifal.cx> wrote:
>
>> On Thu, Dec 26, 2013 at 09:13:59PM -0600, James Gregurich wrote:
>>>
>>>
>>> When I debug my app in gdb, I consistently get “Backtrace stopped:
>>> previous frame inner to this frame (corrupt stack?)” at the lower
>>> end of the backtrace. I set break points at each function in the
>>> back trace and that message persists up to the __clone() invocation.
>>> until that line that I pointed out, the backtrace is normal. Once
>>> that instruction is executed, the backtrace is permanently broken
>>> for that thread.
>>
>> In the backtrace for a thread other than the main thread, it's normal
>> and expected for the backtrace to end at __clone; it's where the
>> thread started. The "corrupt stack" message is unwanted (musl should
>> be arranging for the frame pointer to be zero so that debuggers
>> recognize that there's nothing else on the stack, and maybe this needs
>> fixing) but I don't think it's necessarily indicative of any bug.
>>
>> Rich
>
[-- Attachment #2: Type: text/html, Size: 3916 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-27 22:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-26 22:08 mistake in powerpc clone.s? James Gregurich
2013-12-27 1:57 ` John Spencer
2013-12-27 3:13 ` James Gregurich
2013-12-27 3:42 ` Rich Felker
2013-12-27 3:45 ` James Gregurich
2013-12-27 22:34 ` James Gregurich
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).