[NSWI004] Stuck on syscall return

[Patrik Smelik]

Sorry, forgot to mention, the branch test1 is the one i'm currently using.
Well im working on as6 but didn't want to push it yet since it doesn't
really work.

So we don't need to jump again, that's great. Wasn't sure if it is needed
or not, but it looked like it got better with the jump.
But without the jump, the syscall is called again for some reason and it
tries to print again. And looks like it tries to print something, it
doesn't have access to, since it crashes there. But this time it causes a
kernel panic loop (the one my colleague mention earlier this week). With
this im even more confused.

- PS

ne 16. 2. 2020 o 16:03 Vojtech Horky <horky at d3s.mff.cuni.cz> napísal(a):

> Hello.
>
> Dne 16. 02. 20 v 15:25 Patrik Smelik napsal(a):
> > Hi,
> >
> > Since yesterday, we are stuck on this problem. Userspace process is
>
> It would be extremely useful to send commit hash where the bug is
> reproducible, your master is four weeks old, I do not see implementation
> of print in branch as6...
>
>
> > created fine, syscall handling also works, e.g. for print it prints out
> > what it needs to, but when returning from syscall, i.e. jumping back to
> > userspace, the application suddenly terminates. I fed the
> > cpu_jump_to_userspace function context->sp and context->epc as
> > arguments.The problem is that the context->sp is set to 0 for some
> > reason, which i believe isn't the correct input for the jump. I traced
> > the change to the memcpy method, so to when the binary image is being
> > copied, but i'm currently stuck here.
>
> Not sure I got it right, but when the syscall is handled, the thread
> returns to userspace normally as with any other exception. That is, you
> need to call cpu_jump_to_userspace only once per process.
>
> And you only use context->epc to advance to next instruction as
> otherwise the syscall would be restarted after being handled.
>
> Also note that this function would typically receive two constants:
> address of the top of stack (so something like 0x3f00) and entry point
> as specified in the linker script (0x4000).
>
> As a side note: in one of your commits I see that you panic when the
> syscall id is invalid. That is definitely a bad behavior because any
> application would be easily able to terminate your kernel.
>
> Hope this helps,
> - VH
> _______________________________________________
> NSWI004 mailing list
> NSWI004 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20200216/b6b586a7/attachment.html>