Adjust breakpad module size to match adjusted start_addr.

Adjust breakpad module size to match adjusted start_addr.

When changing a module's start_addr to account for Android packed
relocations, also adjust its size field so that the apparent module
end addr calculated by the breakpad processor does not alter.

Ensures that the mapping entry from a packed library is consistent
with that which an unpacked one would produce.

BUG=499747
R=primiano@chromium.org, rmcilroy@chromium.org

Committed: https://code.google.com/p/google-breakpad/source/detail?r=1465

[simonb (inactive), 2015-06-25 14:40:30]

simonb@chromium.org changed reviewers:
+ primiano@chromium.org, rmcilroy@chromium.org, thestig@chromium.org

[Primiano Tucci (use gerrit), 2015-06-25 14:44:01]

https://codereview.chromium.org/1211863002/diff/1/client/linux/minidump_write...
File client/linux/minidump_writer/linux_dumper.cc (right):

https://codereview.chromium.org/1211863002/diff/1/client/linux/minidump_write...
client/linux/minidump_writer/linux_dumper.cc:520: mapping->size +=
mapping->start_addr - load_bias;
can load_bias ever be > start_addr (maybe by mistakenly parsing the elf header)?
Should you have a check in that case?

[simonb (inactive), 2015-06-25 15:14:36]

https://codereview.chromium.org/1211863002/diff/1/client/linux/minidump_write...
File client/linux/minidump_writer/linux_dumper.cc (right):

https://codereview.chromium.org/1211863002/diff/1/client/linux/minidump_write...
client/linux/minidump_writer/linux_dumper.cc:520: mapping->size +=
mapping->start_addr - load_bias;
On 2015/06/25 14:44:01, Primiano Tucci wrote:
> can load_bias ever be > start_addr (maybe by mistakenly parsing the elf
header)?
> Should you have a check in that case?

From coding errors in the proc/$$/maps or ELF data parsers?  A check here
wouldn't protect.  If start_addr is wrong from misparsing, substituting an
incorrect value for a different incorrect value won't make the result any more
correct.

If load_bias is genuinely > start_addr due to underflow from start_addr being in
very low memory -- beneath 6mb or so say, and a case we hope is pathological --
the symmetrical overflow in this expression means that size still comes out
correctly.  Demo:

#include <iostream>
#include <inttypes.h>
int main() {
  uint32_t start_addr = 0x1000;
  uint32_t size       = 0x200000;
  std::cout << std::hex << "Before: start_addr = " << start_addr
            << ", size = " << size << std::dec << std::endl;
  const uint32_t hole_size  = 0x30000;
  const uint32_t load_bias = start_addr - hole_size;
  // Model a load bias adjustment that wraps start_addr.
  if (load_bias > start_addr)
    std::cout << "Note  : start_addr > load_bias!" << std::endl;
  size += start_addr - load_bias;
  start_addr = load_bias;
  std::cout << std::hex << "After : start_addr = " << start_addr
            << ", size = " << size << std::dec << std::endl;
}

Before: start_addr = 1000, size = 200000
Note  : start_addr > load_bias!
After : start_addr = fffd1000, size = 230000

The case where load_bias can be genuinely > start_addr is a separate breakpad
issue.

[Primiano Tucci (use gerrit), 2015-06-26 08:26:35]

LGTM

[rmcilroy, 2015-06-26 12:36:39]

lgtm.

[simonb (inactive), 2015-06-30 12:48:34]

On 2015/06/26 12:36:39, rmcilroy wrote:
> lgtm.

Thanks Ross.  Would you mind committing this for me through the main breakpad
repo? -- I lack commit privs there.  I'll then pull this forwards through
chromium DEPS roll.  Thx.

[rmcilroy, 2015-06-30 13:30:27]

Committed patchset #1 (id:1) manually as 1465 (presubmit successful).