Replace libdisasm with capstone

Replace libdisasm with capstone

Breakpad has a locally-committed version of libdisasm, which is no
longer developed. Capstone (http://www.capstone-engine.org/) is a
multi-architecture project which is under active development. Using
capstone should provide better support for modern CPU instructions
that may show up in minidumps, as well as bring x86-64 support and
even ARM/AAarch64 support if desired.

This change removes src/third_party/libdisasm, adds capstone's GitHub
repository to DEPS under src/third_party/capstone, fixes the automake
and gyp build systems to build capstone instead of libdisasm, and
fixes the disassembler_x86 and exploitability_win code to use capstone
APIs instead of libdisasm APIs.

The only place where using capstone seems to be less satisfying than
using libdisasm is that capstone lacks the large set of instruction
groups that libdisasm had, such as `libdis::insn_string`. Currently
I have settled for listing out instructions in a switch statement,
which is not terribly satisfying.

Future work could be to support x86-64 in DisassemblerX86 to enable
better exploitability analysis on Windows dumps (easy), replace the
exploitability_linux code that shells out to objdump with
DisassemblerX86 (moderately involved), and build capstone's
ARM/AArch64 backends (easy) and extend the existing
exploitability_linux code to do more thorough analysis of dumps from
those architectures (hard).

R=mark@chromium.org
BUG=

[Ted Mielczarek, 2016-03-22 18:18:50]

Sorry to spring a large patch on you unexpectedly (granted most of it is code
removal). I wanted to see if I could do disassembly of the crashing instruction
to provide better crash addresses for x86-64 crashes that dereference
non-canonical pointers
(https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details). Per
discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=974420, we realized
that crashes at addresses of that form are reported as `0xffffffffffffffff` on
Windows and `0` elsewhere, which is pretty unfortunate. We hit this situation
fairly commonly with things that poison freed memory with patterns like 0x5a5a.
I went looking for a disassembler that supported x86-64 and stumbled upon
capstone, and realized that it might be a nice upgrade from libdisasm.

[Ted Mielczarek, 2016-03-24 20:25:09]

FYI, this is the patch I *wanted* to write, per my previous comment, but I
needed an x86-64 disassembler to do so:
https://github.com/luser/breakpad/commit/c8c0bbcdba178b74db171c21d2c6f4a59efd...

(I don't know how, or if it's possible, to upload dependent patches to Rietveld
without including the changes from the previous patch, so it's on GitHub until
this patch lands.)

[vapier, 2016-03-24 20:30:24]

vapier@chromium.org changed reviewers:
+ vapier@chromium.org

[vapier, 2016-03-24 20:30:25]

rietveld has no concept of dependent changes or different commits and will
happily squash all of them into a single patch here.  it's a tool written in the
cvs/svn world and willfully ignorant of anything newer/saner.

[Ted Mielczarek, 2016-04-01 17:21:11]

I filed an issue upstream about instruction groups being less useful than
libdisasm, and the capstone maintainer is open to taking a patch to add more
groups:
https://github.com/aquynh/capstone/issues/606

If I fix that upstream and update the dep that will make this patch much
cleaner.

[Mark Mentovai, 2016-04-05 00:14:51]

OK, sounds like they’re receptive, so I’ll (keep) hold(ing) off.

[Mark Mentovai, 2016-04-05 00:15:02]

P.S. I’m receptive to this too.

[Ted Mielczarek, 2016-04-05 01:36:08]

On 2016/04/05 00:15:02, Mark Mentovai wrote:
> P.S. I’m receptive to this too.

Great, thanks, your silence was a little worrying since it's kind of an invasive
patch. :) I'll try to get that fix in upstream which should make this patch
better.

[vapier, 2016-06-24 20:09:08]

in general seems pretty good

https://codereview.chromium.org/1821293002/diff/1/src/build/common.gypi
File src/build/common.gypi (right):

https://codereview.chromium.org/1821293002/diff/1/src/build/common.gypi#newco...
src/build/common.gypi:557: '<(werror)',  # See note above about the werror
variable
unrelated/undesirable change ?

https://codereview.chromium.org/1821293002/diff/1/src/build/common.gypi#newco...
src/build/common.gypi:573: '-std=c++11',
this should prob be deployed in a dedicated CL, assuming libdisasm works w/it

https://codereview.chromium.org/1821293002/diff/1/src/third_party/capstone.gyp
File src/third_party/capstone.gyp (right):

https://codereview.chromium.org/1821293002/diff/1/src/third_party/capstone.gy...
src/third_party/capstone.gyp:1: # Copyright 2016 Google Inc. All rights
reserved.
we don't update copyright years

https://codereview.chromium.org/1821293002/diff/1/src/third_party/capstone.gy...
src/third_party/capstone.gyp:48: 'CAPSTONE_HAS_X86',
indentation broken ?