Fix GetLoadingAddress() to work for Native Client executables

Fix GetLoadingAddress() to work for Native Client executables

NaCl executables have ELF program headers that look like this (for the
original NaCl x86 GCC toolchain):

Program Header:
    LOAD off    0x00010000 vaddr 0x00020000 paddr 0x00020000 align 2**16
         filesz 0x00017ce0 memsz 0x00017ce0 flags r-x
    LOAD off    0x00030000 vaddr 0x10020000 paddr 0x10020000 align 2**16
         filesz 0x00001c98 memsz 0x00001c98 flags r--
    LOAD off    0x00040000 vaddr 0x10030000 paddr 0x10030000 align 2**16
         filesz 0x000025ec memsz 0x00002b88 flags rw-

or this (for the newer NaCl ARM GCC toolchain):

Program Header:
    LOAD off    0x00010000 vaddr 0x00020000 paddr 0x00020000 align 2**16
         filesz 0x000193b0 memsz 0x000193b0 flags r-x
    LOAD off    0x00000000 vaddr 0x10020000 paddr 0x10020000 align 2**16
         filesz 0x00000978 memsz 0x00000978 flags r--
    LOAD off    0x00001000 vaddr 0x10031000 paddr 0x10031000 align 2**16
         filesz 0x00000abc memsz 0x00000fac flags rw-

Fix GetLoadingAddress() to return the start address of the first
segment, 0x20000, in these cases.  Looking at p_offset for this isn't
correct, and the first segment doesn't have p_offset == 0 here because
NaCl can't map the ELF file headers as part of the first segment
(which is for validatable code only).

BUG= https://code.google.com/p/nativeclient/issues/detail?id=3424
TEST= check addresses in output of "dump_syms" when run on NaCl nexe

Committed Breakpad r1170

[Roland McGrath]

https://breakpad.appspot.com/588002/diff/1/src/common/linux/dump_symbols.cc
File src/common/linux/dump_symbols.cc (right):

https://breakpad.appspot.com/588002/diff/1/src/common/linux/dump_symbols.cc#n...
src/common/linux/dump_symbols.cc:159: // normally be zero.
For ET_DYN files that have been prelinked, it's nonzero and that's perfectly
normal.  The rest of the comment is correct, and thus the change seems valid.

[Mark Mentovai]

LGTM. Thanks!

Committed Breakpad r1170.