Reland Implement .eh_frame writer and disassembler.

src/arm/eh-frame-arm.h

+// Copyright 2016 the V8 project authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef V8_X64_UNWINDING_INFO_X64_H
+#define V8_X64_UNWINDING_INFO_X64_H
+
+#include "src/globals.h"
+
+namespace v8 {
+namespace internal {
+
+static const int kInitialCFARegister = 0x0b;
+static const int kInitialCFAOffset = 0;
+static const int kDataAlignmentFactor = 4;
+static const int kInitialStateOffsetInCIE = 19;
+
+// The code and data alignments are a bit unorthodox, but they suit our purpose.
+static const byte kCIE[] = {
+    0x14, 0x00, 0x00, 0x00,  // Size of the CIE excluding this field
+    0x00, 0x00, 0x00, 0x00,  // CIE identifier, always 0
+    0x03,                    // CIE version 3
+    0x7a, 0x4c, 0x52, 0x00,  // Augmentation string zLR
+    0x01,                    // Code alignment factor: 1

[rmcilroy, 2016/06/28 10:37:32]

I think we always have code aligned to 4 (or kPointerSize) given the code object
is always pointer aligned. Not sure if this helps or not?

[Stefano Sanfilippo, 2016/06/29 15:16:20]

This is just a constant that is factored out from all offsets in AdvanceLocation
directives. Setting it to 1 means that we can directly use masm()->pc_offset(),
instead of having to divide by kPointerSize. Either ways are fine for me though.

[rmcilroy, 2016/06/30 15:23:10]

I see, this is fine.

+    0x04,                    // Data alignment factor: 4

[rmcilroy, 2016/06/28 10:37:32]

Use kDataAlignmentFactor and other constants here where appropriate

[Stefano Sanfilippo, 2016/06/29 15:16:20]

Replaced kInitialCFAOffset where appropriate.

kDataAlignmentFactor is SLEB128 encoded in the CIE, I can't directly use
kDataAlignmentFactor, unfortunately.

Also, since now we use a Register instead of the integer index, we would need a
constant for the initial CFA register, which would be used only here, wdyt?

[rmcilroy, 2016/06/30 15:23:10]

As mentioned in a new comment in eh-frame-x64, I think you should write the
header using the Write... functionality rather than writing it as a blob - that
will allow you to use WriteSLEB to encode this.

+    0x0e,                    // Return address register: lr (r14)
+    0x02,                    // Length of augmentation data
+    0xff,                    // No LSDA
+    0x1b,                    // FDE encoding: DW_EH_PE_sdata4 | DW_EH_PE_pcrel
+    // Initial state
+    0x0c, 0x0b, 0x00,  // CFA @ fp+0
+    0x08, 0x0e,        // lr valid
+};
+
+}  // namespace internal
+}  // namespace v8
+
+#endif