Skip to content
Snippets Groups Projects
  • Andrew Burgess's avatar
    8a3b1706
    gdb/python: break more dependencies between gdbpy_initialize_* functions · 8a3b1706
    Andrew Burgess authored
    In a later commit in this series I will propose removing all of the
    explicit gdbpy_initialize_* calls from python.c and replace these
    calls with a more generic mechanism.
    
    One of the side effects of this generic mechanism is that the order in
    which the various Python sub-systems within GDB are initialized is no
    longer guaranteed.
    
    On the whole I don't think this matters, most of the sub-systems are
    independent of each other, though testing did reveal a few places
    where we did have dependencies, though I don't think those
    dependencies were explicitly documented in comment anywhere.
    
    This commit is similar to the previous one, and fixes the second
    dependency issue that I found.
    
    In this case the finish_breakpoint_object_type uses the
    breakpoint_object_type as its tp_base, this means that
    breakpoint_object_type must have been initialized with a call to
    PyType_Ready before finish_breakpoint_object_type can be initialized.
    
    Previously we depended on the ordering of calls to
    gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in
    python.c.
    
    After this commit a new function gdbpy_breakpoint_init_breakpoint_type
    exists, this function ensures that breakpoint_object_type has been
    initialized, and can be called from any gdbpy_initialize_* function.
    
    I feel that this change makes the dependency explicit, which I think
    is a good thing.
    
    There should be no user visible changes after this commit.
    8a3b1706
    History
    gdb/python: break more dependencies between gdbpy_initialize_* functions
    Andrew Burgess authored
    In a later commit in this series I will propose removing all of the
    explicit gdbpy_initialize_* calls from python.c and replace these
    calls with a more generic mechanism.
    
    One of the side effects of this generic mechanism is that the order in
    which the various Python sub-systems within GDB are initialized is no
    longer guaranteed.
    
    On the whole I don't think this matters, most of the sub-systems are
    independent of each other, though testing did reveal a few places
    where we did have dependencies, though I don't think those
    dependencies were explicitly documented in comment anywhere.
    
    This commit is similar to the previous one, and fixes the second
    dependency issue that I found.
    
    In this case the finish_breakpoint_object_type uses the
    breakpoint_object_type as its tp_base, this means that
    breakpoint_object_type must have been initialized with a call to
    PyType_Ready before finish_breakpoint_object_type can be initialized.
    
    Previously we depended on the ordering of calls to
    gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in
    python.c.
    
    After this commit a new function gdbpy_breakpoint_init_breakpoint_type
    exists, this function ensures that breakpoint_object_type has been
    initialized, and can be called from any gdbpy_initialize_* function.
    
    I feel that this change makes the dependency explicit, which I think
    is a good thing.
    
    There should be no user visible changes after this commit.
py-breakpoint.c 43.70 KiB