[PATCH/RFC] Per-architecture DWARF CFI register state initialization hooks
Andrew Cagney
cagney@gnu.org
Mon Feb 16 20:50:00 GMT 2004
>> Sorry, my analysis wasn't completely correct. What actually happens
>> is an init-order problem during the initialization of the gdbarch
>> in initialize_current_architecture. The problem is that I call
>> dwarf2_frame_set_init_reg from within the s390_gdbarch_init routine
>> (which I gather is the right place?), and at this point in time,
>> the gdbarch_data call in dwarf2_frame_set_init_reg returns NULL
>> because the gdbarch hasn't finished initialization yet:
I've committed the attatched. It follows the convention described in
that revised doco patch I posted:
http://sources.redhat.com/ml/gdb-patches/2004-02/msg00381.html
Andrew
>> gdbarch_data (struct gdbarch *gdbarch, struct gdbarch_data *data)
>> {
>> gdb_assert (data->index < gdbarch->nr_data);
>> /* The data-pointer isn't initialized, call init() to get a value but
>> only if the architecture initializaiton has completed. Otherwise
>> punt - hope that the caller knows what they are doing. */
>> if (gdbarch->data[data->index] == NULL
>> && gdbarch->initialized_p)
>
>
> Oopsie. Yes, now I can see what's going on - I'm not sure what should
> change here. Andrew, do you recall if the initialized_p check was for
> any specific problem, or might we be able to remove it?
>
> -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
More information about the Gdb-patches
mailing list