Hi Andrew,

Use a different description that fits within 80 columns.

Rebase.

In D13148#276247, @andrew wrote:

Maybe you're referring to switching between 64-bit and 32-bit code without going through EL1 first. This is explicitly documented as unsupported.

No, from memory it was an incorrect check the value passed to the kernel from userspace was wrong. I did make sure we have a check on signal return, however for it to work we need to check M[4] is set correctly. With this change the user could change this bit.

Don't allow PSR_AARCH32 to be set in sigreturn().

Considering that there is no need to split up this into two code paths for 32-bit/64-bit at least for what I'm trying to achieve, would you mind if I went ahead, committing this change as is? Once this change and D13148 land, I can work towards getting the sysent for cloudabi32 committed.

Revert changes to cpu_set_upcall().

Kostik, I see there are also some places where we set td_retval from within cpu_set_upcall(). That should be unnecessary altogether, right? Even without this change, we don't end up calling cpu_set_syscall_retval() after thread creation....

In D13180#274501, @kib wrote:

I do not see changes for e.g. sparc64 where exec_setregs() also sets td_retval.

We can also remove td_retval handling in the thread initialization.

Remove dead code from sparc64. Spotted by kib@.

In D13180#274429, @kib wrote:

Note my comment at the return() in do_execve().

Document why we return EJUSTRETURN in do_execve().

Remove a stale comment regarding regs <-> retval.

Make sure sure this comment doesn't contain a typo.

Take a look at all kern_execve() call sites. Fix up linux_common_execve().

Process kib@'s feedback. Thanks!

In D13148#273916, @andrew wrote:

In D13148#273913, @ed wrote:

This would be benign, right? For the kernel, it is irrelevant whether user space sets or clears this flag. Just like NZCV, etc.

I'm not sure how the kernel would handle userspace changing between 64 and 32 bit code.

In D13148#273883, @andrew wrote:

This will allow userspace to switch between AArch64 and AArch32 via sigreturn. sys_sigreturn has checks on the PSR bits to ensure they are safe to install that this will break.

In D13146#273882, @andrew wrote:

I split the syncronous exception out into a new handler in my compat32 patch as it allows further sanity checks, e.g. that the kernel thinks the current process should be in 32-bit mode.

In D13145#273886, @andrew wrote:

Are we expecting to run armv6 code, or should we just support armv7?

Announce armv7 instead of armv6.

Looks a lot better. Thanks!

In D12785#267382, @cy wrote:

The gets_s() has been separated out into a different file.

Would it be better to svn copy & update or a new file from scratch?

I'm personally not a fan of the *_s() functions. That said, we've already added some others to the base system, so there's probably no turning back.

What about making the macros identical? That way there is no need for a guard. s/field/member/