The major-looking code changes were all just to unravel some gotos.

Change-Id: I86f98a48b160f357ce93c87446bad5d705d5f05b

Moved from ZipArchive.c, with tweaks to for argument order and name. Also
tweaked a related function in ZipArchive to match.

Change-Id: I4d2e3c8b44386d87c5aa1c4565f72da87357fce8

Change-Id: I1e3d103a7b932ef21acedb6438c0f26b315df28f

Implement enh's idea about repeating write() until it fails.  Use it
in the zip expander and dexopt, which have an above-average chance of
failing due to lack of disk space.

Replace a stray DEFAULT_PAGE_SIZE with SYSTEM_PAGE_SIZE.  Apparently I
missed that during the Great Page Size Unification.

Change-Id: Id173cb7669330deebe2f24ae23ece4009a90e3bd

Change the way zip archives are handled.  This is necessary to deal with
very large (~1GB) APK files, for which our current approach of mapping
the entire file falls over.

We now do the classic scavenger hunt for the End Of Central Directory magic
on a buffer of data read from the file, instead of a memory-mapped section.
We use what we find to create a map that covers the Central Directory only.
For most uses in the VM this is all we really need, since we just want
to check file attributes vs. the optimized DEX to see if we're out of date.

If the caller is interested in unpacking the file contents, we have to
do an additional file read to discover the size of the Local File Header
section so we can skip past it.  We also now do a file-to-file extraction
using read() calls instead of a buffer-to-file extraction on mmap()ed data.
No difference in performance (as measured by first-boot dexopt).

Since this is more of a rewrite than an update, I also took the opportunity
to change buffer size variables from "long" to "size_t", and normalized
return values to int (some were using bool, which is common in the VM but
was mixed in the zip code).  Failure messages are now all LOGW with the
word "Zip" up front (didn't want to change log tag away from "dalvikvm").

Also, removed a not-quite-right check in the "map part of a file" code,
and clarified that the file offset is absolute.

For bug 2620103.

Change-Id: I745fb15abb541376f467969ffe422222676f1e5f

Broken by 96516932f1557d8f48a8b2dbbb885af01a11ef6e.

The recent change to mmap(read-write)+mprotect(read-only) doesn't seem
to work on FAT filesystems like /sdcard.  This caused problems for the
code that opens Zip files and the code that opens DEX files.

This change splits the "map file" function into "read only" and
"writable read only" versions, using the former for Zip and the latter
for DEX.  Further, failure to mprotect(read-only) is now considered a
soft failure and only causes a warning.

The only apps that will be affected by this are those using /sdcard to
hold optimized DEX data for "plugin" APKs.

Also: moved the non-HAVE_POSIX_FILEMAP implementation of file mapping
into a shared function.  (Could probably go away entirely.)

Also: fixed the expected output for test 071.

This replaces the breakpoint mechanism with a more efficient approach.
We now insert breakpoint instructions into the bytecode stream instead of
maintaining a table.  This requires mapping DEX files as private instead
of shared, which allows copy-on-write to work.  mprotect() is used to
guard the pages against inadvertent writes.

Unused opcode EC is now OP_BREAKPOINT.  It's not recognized by dexdump or
any interpreter except portdbg, but it can be encountered by the bytecode
verifier (the debugger can request breakpoints in unverified code).
Breakpoint changes are blocked while the verifier runs to avoid races.

This eliminates method->debugBreakpointCount, which is no longer needed.
(Also, it clashed with LinearAlloc's read-only mode.)

The deferred verification error mechanism was using a code-copying
approach to modify the bytecode stream.  That has been changed to use
the same copy-on-write modification mechanism.

Also, normalized all PAGE_SIZE/PAGESIZE references to a single
SYSTEM_PAGE_SIZE define.

Simple Fibonacci computation test times (opal-eng):
  JIT, no debugger: 10.6ms
  Fast interp, no debugger: 36ms
  Portable interp, no debugger: 43.8ms

  ORIG debug interp, no breakpoints set: 458ms
  ORIG debug interp, breakpoint set nearby: 697ms

  NEW debug interp, no breakpoints set: 341ms
  NEW debug interp, breakpoints set nearby: 341ms

Where "nearby" means there's a breakpoint in the method doing the
computation that isn't actually hit -- the VM had an optimization where
it flagged methods with breakpoints and skipped some of the processing
when possible.

The bottom line is that code should run noticeably faster while a
debugger is attached.