Revert r15: Fix the calling conventions for the sixth argument on i386

Revert r15: Fix the calling conventions for the sixth argument on i386

The change in r15 was incorrect and it breaks nacl_helper_bootstrap on
Linux, which calls mmap() (which takes 6 arguments) via
linux_syscall_support.h.

BUG=none
TEST=run_hello_world_test in NaCl on x86-32

Committed: https://code.google.com/p/linux-syscall-support/source/detail?r=16

[Markus (顧孟勤), 2012-10-27 17:09:48]

lgtm

I am thoroughly confused now.

Julien made a very good argument that in i386, the six parameter is passed on
the stack. He showed me the code in the kernel and I even double-checked by
disassembling the vsyscall entry point.

The vsyscall clearly pushes the parameter on the stack and then passes an
address to it, prior to entering the kernel.

And as we don't go through the vsyscall, I would have assumed we have to do the
same. I guess, I am wrong. I just don't understand why.

So, yes, please go ahead and revert; and if anybody can explain where we went
wrong, please do so.

I hear you about wanting to use the standard code-review tools. I didn't know
that actually works for this repository; but if it does, then all the better.

[Mark Seaborn, 2012-10-27 17:46:55]

On 27 October 2012 10:09, <markus@chromium.org> wrote:

> lgtm
>
> I am thoroughly confused now.
>
> Julien made a very good argument that in i386, the six parameter is passed
> on
> the stack. He showed me the code in the kernel and I even double-checked by
> disassembling the vsyscall entry point.
>
> The vsyscall clearly pushes the parameter on the stack and then passes an
> address to it, prior to entering the kernel.
>
> And as we don't go through the vsyscall, I would have assumed we have to
> do the
> same. I guess, I am wrong. I just don't understand why.
>
> So, yes, please go ahead and revert; and if anybody can explain where we
> went
> wrong, please do so.
>

When you say vsyscall, do you mean the __kernel_vsyscall entry point in the
VDSO?  The last time I dumped that, it contained:

ffffe420 <__kernel_vsyscall>:
ffffe420:       cd 80                   int    $0x80
ffffe422:       c3                      ret

When I look at recent kernel sources, that code comes from
arch/x86/vdso/vdso32/int80.S.

You must be thinking of the faster path that uses the sysenter instruction
rather than 'int $0x80'.  The user mode side of that is in
arch/x86/vdso/vdso32/sysenter.S.  The kernel side is in
arch/x86/ia32/ia32entry.S.  See ia32_sysenter_target, where it says:

 * Arguments:
 * %eax    System call number.
 * %ebx Arg1
 * %ecx Arg2
 * %edx Arg3
 * %esi Arg4
 * %edi Arg5
 * %ebp user stack
 * 0(%ebp) Arg6

But here, %ebp is used for restoring %esp as well as passing argument 6,
because the sysenter instruction clobbers %esp.  Also, I expect this
interface is not intended to be a stable ABI:  it is a private interface
between the VDSO and the kernel, just for the sysenter-based fast path.


I hear you about wanting to use the standard code-review tools. I didn't
> know
> that actually works for this repository; but if it does, then all the
> better.
>

Yes, git-cl works on any SVN repo, and I expect gcl does too.  The
codereview.settings file in the repo provides some of the setup.

Cheers,
Mark