Messages in this thread | | | Date | Thu, 16 Aug 2001 17:12:48 +0100 | From | Russell King <> | Subject | Re: How should nano_sleep be fixed (was: ptrace(), fork(), sleep(), exit(), SIGCHLD) |
| |
On Thu, Aug 16, 2001 at 06:00:10PM +0200, christophe barbé wrote: > Le jeu, 16 aoû 2001 12:29:05, Russell King a écrit : > > Note also that this is bogus as an architecture invariant. > > > > On ARM, we have to pass a pt_regs pointer into any function that requires > > it. > > I'm not sure to understand your point.
Its quite simple:
int sys_foo(struct pt_regs regs) { }
does not reveal the user space registers on ARM. It instead reveals crap. Why? The ARM procedure call standard specifies that the first 4 words of "regs" in this case are in 4 processor registers. The other words are on the stack immediately above the frame created by foo. This is not how the stack is layed out on ARM on entry to a sys_* function due to the requirement for these to be restartable.
Instead, we must pass a pointer thusly:
int sys_foo(struct pt_regs *regs) { }
and the pointer is specifically setup and passed in by a very small assembler wrapper.
> The first sentence tell me that the "struct pt_regs ..." line is x86 > specific and this was the reason behind my proposition to not add a _signal > macro but a _sys_nanosleep macro to include this too.
Correct. But the act of getting "struct pt_regs" on entry to the function is also architecture specific.
> The second sentence seem's to indicate that this is a classic problem for > the ARM port. So if this is correct what is the best way to solve it ?
It used to be with such functions as sys_execve. Then, sys_execve became an architecture specific wrapper around do_execve (not by my hand), so I guess that its not an ARM specific problem.
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |