Change startup ABI for untrusted code to be C-compatible

Change startup ABI for untrusted code to be C-compatible

This changes the trusted runtime to start up untrusted code with an
ABI that is compatible with the normal C ABI for the machine.  Rather
than having a special machine-dependent ABI for the entry point, the
entry point is now expected to be a normal C function of one argument.
That argument is a pointer onto the stack, where lies the information
previously passed there, but now in a uniform machine-independent format.

This entails some changes in the trusted code to do the appropriate
machine-dependent setup of the stack and registers.

In the untrusted runtime libraries, it removes a great deal of
assembly code now that the entry point function _start can be written
entirely in C.  Since it's pure C, the whole startup path is much more
PNaCl-friendly.

This makes it possible to clean up the IRT startup a bit more too,
since it's easy to just use its own variant of that simple C function.

Before this can land, it will require corresponding changes to the
startup code in glibc and its dynamic linker, which will be reviewed
separately.  There will need to be a multi-stage deployment in which
the toolchains get updated and then this change lands with a toolchain
DEPS update included in the same commit.

Note that this makes all old nexe binaries no longer work (if they
need their arguments, environment, or auxv, which is used to work with
the IRT).  This is a hard break and we don't intend to provide any
compatibility for old nexes or old IRT images.  Any application
rebuilt with the new toolchains (newlib or glibc, native or pnacl)
should work without source changes.

BUG=http://code.google.com/p/nativeclient/issues/detail?id=1131
TEST=pending

R=bsy@google.com,sehr@google.com

Committed: http://src.chromium.org/viewvc/native_client?view=rev&revision=5900

[Roland McGrath, 2011-06-28 22:20:49]

I am still debugging some of the associated glibc changes, and there is at least
one other test nit remaining.

But this is ready to get some review.
The trusted code parts and the bulk of the untrusted library changes are working
and already how I think they'll stay.

PTAL


Thanks,
Roland

[sehr (please use chromium), 2011-06-29 17:34:35]

On 2011/06/28 22:20:49, Roland McGrath wrote:
> I am still debugging some of the associated glibc changes, and there is at
least
> one other test nit remaining.
> 
> But this is ready to get some review.
> The trusted code parts and the bulk of the untrusted library changes are
working
> and already how I think they'll stay.
> 
> PTAL
> 
> 
> Thanks,
> Roland

Looks great.  LGTM.

[bsy, 2011-06-29 18:23:07]

lgtm for tcb code.

http://codereview.chromium.org/7276050/diff/1/src/trusted/service_runtime/sel...
File src/trusted/service_runtime/sel_ldr_standard.c (right):

http://codereview.chromium.org/7276050/diff/1/src/trusted/service_runtime/sel...
src/trusted/service_runtime/sel_ldr_standard.c:836: if
(NACL_STACK_PAD_BELOW_ALIGN != 0) {
if NACL_STACK_PAD_BELOW_ALIGN is zero, i bet the compilers are smart enough --
with memset an intrinsic -- that the if is actually not needed.  dead code
elimination of the constant boolean expression vs DCE of subtraction by zero and
memset of zero length....  i think it's slightly more readable to not have the
if, but your choice.

[Roland McGrath, 2011-06-29 19:54:02]

On 2011/06/29 18:23:07, bsy wrote:
> lgtm for tcb code.
> 
>
http://codereview.chromium.org/7276050/diff/1/src/trusted/service_runtime/sel...
> File src/trusted/service_runtime/sel_ldr_standard.c (right):
> 
>
http://codereview.chromium.org/7276050/diff/1/src/trusted/service_runtime/sel...
> src/trusted/service_runtime/sel_ldr_standard.c:836: if
> (NACL_STACK_PAD_BELOW_ALIGN != 0) {
> if NACL_STACK_PAD_BELOW_ALIGN is zero, i bet the compilers are smart enough --
> with memset an intrinsic -- that the if is actually not needed.  dead code
> elimination of the constant boolean expression vs DCE of subtraction by zero
and
> memset of zero length....  i think it's slightly more readable to not have the
> if, but your choice.

That was my preference too, but I thought others might find it overly magical to
assume the harmlessness of the zero case.
Changed.


Thanks,
Roland