Initial support for emitting unwinding information in perf jitdump.

src/eh-frame.cc

Index: src/eh-frame.cc
diff --git a/src/eh-frame.cc b/src/eh-frame.cc
new file mode 100644
index 0000000000000000000000000000000000000000..6bc60499e252403e9f82f48613ed26d892598cb4
--- /dev/null
+++ b/src/eh-frame.cc
@@ -0,0 +1,90 @@
+// 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.
+
+#include "src/eh-frame.h"
+#include "src/objects-inl.h"
+#include "src/objects.h"
+
+namespace v8 {
+namespace internal {
+
+static const int DW_EH_PE_pcrel = 0x10;
+static const int DW_EH_PE_datarel = 0x30;
+static const int DW_EH_PE_udata4 = 0x03;
+static const int DW_EH_PE_sdata4 = 0x0b;
+
+const int EhFrameHdr::kCIESize = 0;
+
+//
+// In order to calculate offsets in the .eh_frame_hdr, we must know the layout
+// of the DSO generated by perf inject, which is assumed to be the following:
+//
+//  |      ...      |                        |
+//  +---------------+ <-- (F) ---            |  Larger offsets in file
+//  |               |           ^            |
+//  |  Instructions |           | .text      v
+//  |               |           v
+//  +---------------+ <-- (E) ---
+//  |///////////////|
+//  |////Padding////|
+//  |///////////////|
+//  +---------------+ <-- (D) ---
+//  |               |           ^
+//  |      CIE      |           |
+//  |               |           |
+//  +---------------+ <-- (C)   | .eh_frame
+//  |               |           |
+//  |      FDE      |           |
+//  |               |           v
+//  +---------------+ <-- (B) ---
+//  |    version    |           ^
+//  +---------------+           |
+//  |   encoding    |           |
+//  |  specifiers   |           |
+//  +---------------+ <---(A)   | .eh_frame_hdr
+//  |   offset to   |           |
+//  |   .eh_frame   |           |
+//  +---------------+           |
+//  |      ...      |          ...
+//
+//  (F) is aligned at a 16-byte boundary.
+//  (D) is aligned at a  8-byte boundary.
+//  (B) is aligned at a  4-byte boundary.
+//  (E), (C) and (A) have no alignment requirements.
+//
+// The size of the .eh_frame is required to be a multiple of the pointer size,
+// which means that (B) will always be aligned to a 4-byte boundary on all the
+// architectures we support. Instead, there could be padding between (E) and (D)
+// to reach the appropriate alignment. Since (F) is aligned at a 16-byte
+// boundary, thus to a 8-byte one as well, we have D - F = RoundUp(E - F, 8),
+// which means we don't need to know the absolute value of E.

[rmcilroy, 2016/06/24 09:45:25]

I'm not sure what the "Instead..." sentence really means. Do we need to know
that in this file? It doesn't look like you need to know the location of (E)
here, is that right?

[Stefano Sanfilippo, 2016/06/24 10:36:37]

The point is that we are guaranteed that there will never be padding between the
.eh_frame and the .eh_frame_hdr, because (B) already has the correct alignment.
Instead, E does not have any alignment requirement, so there might be padding
between E and D. The next aligned address after E (i.e. the location of D) is
RoundUp(E, 8) = RoundUp(F + <.text size>, 8), which means the distance F -> D is
RoundUp(F + <.text size>, 8) - F. So we would need to know either E or F.
However, since F is 8-byte aligned, we can simplify the calculation above as F +
RoundUp(<.text size>, 8) - F = RoundUp(<.text size>, 8).

Yes, we don't need to know the absolute values of E or F, but only because we
are in a particular case, and I felt I needed to make that explicit.

+//
+EhFrameHdr::EhFrameHdr(Code* code) {
+  int code_size = code->is_crankshafted() ? code->safepoint_table_offset()
+                                          : code->instruction_size();

[rmcilroy, 2016/06/24 09:45:26]

Looks like this code is in a couple of places (e.g., perf-jit). As a followup CL
maybe we could add a helper function for this onto the code object.

[Stefano Sanfilippo, 2016/06/24 10:36:37]

Sure thing, maybe let's coordinate with jarin@.

+  version_ = 1;
+  eh_frame_ptr_encoding_ = DW_EH_PE_sdata4 | DW_EH_PE_pcrel;
+  lut_size_encoding_ = DW_EH_PE_udata4;
+  lut_entries_encoding_ = DW_EH_PE_sdata4 | DW_EH_PE_datarel;
+
+  // .eh_frame pointer and LUT
+  if (code->has_unwinding_info()) {
+    DCHECK_GE(code->unwinding_info_size(), EhFrameHdr::kRecordSize);
+    int eh_frame_size = code->unwinding_info_size() - EhFrameHdr::kRecordSize;
+
+    offset_to_eh_frame_ = -(eh_frame_size + 4);  // A -> D

[rmcilroy, 2016/06/24 09:45:25]

Where does the "+ 4" come from? Could you make the 4 a constant so that it is
clear.

[Stefano Sanfilippo, 2016/06/24 10:36:36]

+ 4 is the size of <version> (1 byte) and <encoding specifiers> (3 byte) in the
diagram above. Maybe I could write "4 byte" next to the A->B interval?

[rmcilroy, 2016/06/24 12:55:25]

Why not just have two constants: kVersionSize and kEncodingSpecifiersSize, that
would make this clear without additional comments.

[Stefano Sanfilippo, 2016/06/24 13:17:28]

Done.

+    lut_entries_number_ = 1;
+    offset_to_procedure_ = -(RoundUp(code_size, 8) + eh_frame_size);  // B -> F
+    offset_to_fde_ = -(eh_frame_size - kCIESize);                     // B -> C
+  } else {
+    // Create a dummy table
+    offset_to_eh_frame_ = 0;
+    lut_entries_number_ = 0;
+    offset_to_procedure_ = 0;
+    offset_to_fde_ = 0;
+  }
+}
+
+}  // namespace internal
+}  // namespace v8