[PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks
Ulrich Weigand
weigand@i1.informatik.uni-erlangen.de
Mon Feb 16 01:28:00 GMT 2004
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
More information about the Gdb-patches
mailing list