Re: [PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks

[Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>]

Mark Kettenis wrote:

+/* Return a default for the architecture-specific operations.  */
+
+static void *
+dwarf2_frame_init (struct gdbarch *gdbarch)
+{
+  struct dwarf2_frame_ops *ops;
+  
+  ops = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct dwarf2_frame_ops);
+  ops->init_reg = dwarf2_frame_default_init_reg;
+  return ops;
+}
+
+/* Set the architecture-specific register state initialization
+   function for GDBARCH to INIT_REG.  */
+
+void
+dwarf2_frame_set_init_reg (struct gdbarch *gdbarch,
+                          void (*init_reg) (struct gdbarch *, int,
+                                            struct dwarf2_frame_state_reg *))
+{
+  struct dwarf2_frame_ops *ops;
+
+  ops = gdbarch_data (gdbarch, dwarf2_frame_data);
+  ops->init_reg = init_reg;
+}

Unfortunately this now crashes on s390, because the 
dwarf2_frame_init routine is called from within
_initialize_dwarf2_frame, while the s390 backend calls
dwarf2_frame_set_init_reg from within _initialize_s390_tdep.

Now, in the generated initialize_all_files routine, the
s390_tdep init routine is called *before* the dwarf2_frame
one, and hence dwarf2_frame_set_init_reg gets called before
dwarf2_frame_init.

Thus, the gdbarch_data call returns NULL, and the assignment
to ops->init_reg crashes.

Is there some usual way to solve this sort of init-order
issues with the gdb init sequence?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de