+ int first = 1;
+
+ /* There are at least 3 possibilities to share an unwind info entry:
+ 1. Two different runtime_function entries (in .pdata) can point to the
+ same unwind info entry. There is no such indication while unwinding,
+ so we don't really care about that case. We suppose this scheme is
+ used to save memory when the unwind entries are exactly the same.
+ 2. Chained unwind_info entries, with no unwind codes (no prologue).
+ There is a major difference with the previous case: the pc range for
+ the function is different (in case 1, the pc range comes from the
+ runtime_function entry; in case 2, the pc range for the chained entry
+ comes from the first unwind entry). Case 1 cannot be used instead as
+ the pc is not in the prologue. This case is officially documented.
+ (There might be unwind code in the first unwind entry to handle
+ additional unwinding). GCC (at least until gcc 5.0) doesn't chain
+ entries.
+ 3. Undocumented unwind info redirection. Hard to know the exact purpose,
+ so it is considered as a memory optimization of case 2.
+ */
+
+ if (unwind_info & 1)
+ {
+ /* Unofficially documented unwind info redirection, when UNWIND_INFO
+ address is odd (http://www.codemachine.com/article_x64deepdive.html).
+ */
+ struct external_pex64_runtime_function d;
+
+ if (target_read_memory (cache->image_base + (unwind_info & ~1),
+ (gdb_byte *) &d, sizeof (d)) != 0)
+ return;
+
+ cache->start_rva
+ = extract_unsigned_integer (d.rva_BeginAddress, 4, byte_order);
+ cache->end_rva
+ = extract_unsigned_integer (d.rva_EndAddress, 4, byte_order);
+ unwind_info
+ = extract_unsigned_integer (d.rva_UnwindData, 4, byte_order);
+ }