start_thread question...

start_thread question...

[Dave Airlie]

I'm implementing start_thread for the VAX port and am wondering does
start_thread have to return to load_elf_binary? I'm working on the init
thread and what is happening is it is returning the whole way back to the
execve caller .. which I know shouldn't happen.....

so I suppose what I'm looking for is the point where the user space code
gets control... is it when the registers are set in the start_thread? if
so how does start_thread return....

On the VAX we have to call a return from interrupt to get to user space
and I'm trying to figure out where this should happen...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person

Re: start_thread question...

[Ingo Molnar]

On Sun, 20 May 2001, Dave Airlie wrote:

> I'm implementing start_thread for the VAX port and am wondering does
> start_thread have to return to load_elf_binary? I'm working on the
> init thread and what is happening is it is returning the whole way
> back to the execve caller .. which I know shouldn't happen.....

start_thread() doesnt do what one would intuitively think it does.

start_thread() simply prepares the new task's register set to be ready to
start user-space (which task is the current task as well, so certain
current CPU registers might have to be manually bootstrapped as well), but
start_thread() does not actually start execution of user-space code yet.

(a more correct name for start_thread() would be prepare_user_thread().)

> so I suppose what I'm looking for is the point where the user space
> code gets control... is it when the registers are set in the
> start_thread? if so how does start_thread return....

execution starts when the process returns from sys_execve(). By that time
we have already changed pagetables and other context information, dropped
basically everything from the previous context - without actually doing a
context-switch. In fact sys_execve() has an implicit context-switch,
without ever changing the kernel-stack though.

> On the VAX we have to call a return from interrupt to get to user
> space and I'm trying to figure out where this should happen...

this is how it happens on x86 too. Basically you start the new binary by
returning from an syscall that has bootstrapped all userspace context -
this approach should work on any architecture. (because every architecture
has to be able to execute user-space code after syscalls.)

	Ingo

Re: start_thread question...

[Jeff Dike]

airlied@skynet.ie said:
> I'm implementing start_thread for the VAX port and am wondering does
> start_thread have to return to load_elf_binary? I'm working on the
> init thread and what is happening is it is returning the whole way
> back to the execve caller .. which I know shouldn't happen.....

Ingo answered that specific question (and that had me puzzled for a while, too 
:-), but, in the future, you might want to look at UML if you have similar 
questions.  All this stuff works, and it's implemented in terms of the system 
calls that we all know and love, so you don't have to learn about a totally 
different piece of hardware in order to figure out what's going on.

				Jeff

Re: [LV] start_thread question...

[Kenn Humborg]

On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote:
> 
> I'm implementing start_thread for the VAX port and am wondering does
> start_thread have to return to load_elf_binary? I'm working on the init
> thread and what is happening is it is returning the whole way back to the
> execve caller .. which I know shouldn't happen.....
> 
> so I suppose what I'm looking for is the point where the user space code
> gets control... is it when the registers are set in the start_thread? if
> so how does start_thread return....
> 
> On the VAX we have to call a return from interrupt to get to user space
> and I'm trying to figure out where this should happen...

I haven't got time to look at this in detail, but you could
probably do it by frobbing the saved registers that will be
restored by the ret_from_syscall in entry.S.  Do you have
a pt_regs *regs function argument at the right point?  If
so, it should point to these saved registers.

Later,
Kenn

Re: [LV] start_thread question...

[Dave Airlie]

Okay I think I've gotten it solved most of the way, we weren't calling
execve via the system call interface, so once I made it go via the system
call and I fill out pc, sp and psl registers in start_thread, it seems to
go further..

Thanks for all the help...

Dave.

On Sun, 20 May 2001, Kenn Humborg wrote:

> On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote:
> >
> > I'm implementing start_thread for the VAX port and am wondering does
> > start_thread have to return to load_elf_binary? I'm working on the init
> > thread and what is happening is it is returning the whole way back to the
> > execve caller .. which I know shouldn't happen.....
> >
> > so I suppose what I'm looking for is the point where the user space code
> > gets control... is it when the registers are set in the start_thread? if
> > so how does start_thread return....
> >
> > On the VAX we have to call a return from interrupt to get to user space
> > and I'm trying to figure out where this should happen...
>
> I haven't got time to look at this in detail, but you could
> probably do it by frobbing the saved registers that will be
> restored by the ret_from_syscall in entry.S.  Do you have
> a pt_regs *regs function argument at the right point?  If
> so, it should point to these saved registers.
>
> Later,
> Kenn
>
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person