* [PATCH 1/7] gdb: remove unused argument from gdb_init
2021-04-22 21:02 [PATCH 0/7] New options to control how Python is initialized Andrew Burgess
@ 2021-04-22 21:02 ` Andrew Burgess
2021-04-23 14:15 ` Tom Tromey
2021-04-22 21:02 ` [PATCH 2/7] gdb: ensure SIGINT is set to SIG_DFL during initialisation Andrew Burgess
` (5 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Andrew Burgess @ 2021-04-22 21:02 UTC (permalink / raw)
To: gdb-patches
The argument to gdb_init is not used, remove it.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (captured_main_1): Don't pass argument to gdb_init.
* top.c (gdb_init): Remove unused argument, and add header
comment.
* top.h (gdb_init): Remove argument.
---
gdb/ChangeLog | 7 +++++++
gdb/main.c | 2 +-
gdb/top.c | 4 +++-
gdb/top.h | 2 +-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/gdb/main.c b/gdb/main.c
index 60c08fb83dd..652e6f76fa0 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -1039,7 +1039,7 @@ captured_main_1 (struct captured_main_args *context)
gdb::alternate_signal_stack signal_stack;
/* Initialize all files. */
- gdb_init (gdb_program_name);
+ gdb_init ();
/* Process early init files and early init options from the command line. */
if (!inhibit_gdbinit)
diff --git a/gdb/top.c b/gdb/top.c
index ecd90a1433a..b58cd4facfc 100644
--- a/gdb/top.c
+++ b/gdb/top.c
@@ -2360,8 +2360,10 @@ The second argument is the terminal the UI runs on."), &cmdlist);
set_cmd_completer (c, interpreter_completer);
}
+/* See top.h. */
+
void
-gdb_init (char *argv0)
+gdb_init ()
{
saved_command_line = xstrdup ("");
previous_saved_command_line = xstrdup ("");
diff --git a/gdb/top.h b/gdb/top.h
index 9438e52331b..56bd06c698b 100644
--- a/gdb/top.h
+++ b/gdb/top.h
@@ -271,7 +271,7 @@ extern void set_prompt (const char *s);
extern int gdb_in_secondary_prompt_p (struct ui *ui);
/* Perform _initialize initialization. */
-extern void gdb_init (char *);
+extern void gdb_init ();
/* For use by event-top.c. */
/* Variables from top.c. */
--
2.25.4
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 1/7] gdb: remove unused argument from gdb_init
2021-04-22 21:02 ` [PATCH 1/7] gdb: remove unused argument from gdb_init Andrew Burgess
@ 2021-04-23 14:15 ` Tom Tromey
0 siblings, 0 replies; 24+ messages in thread
From: Tom Tromey @ 2021-04-23 14:15 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
Andrew> The argument to gdb_init is not used, remove it.
Andrew> There should be no user visible changes after this commit.
Andrew> gdb/ChangeLog:
Andrew> * main.c (captured_main_1): Don't pass argument to gdb_init.
Andrew> * top.c (gdb_init): Remove unused argument, and add header
Andrew> comment.
Andrew> * top.h (gdb_init): Remove argument.
Looks good, obvious even. Thanks.
Tom
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 2/7] gdb: ensure SIGINT is set to SIG_DFL during initialisation
2021-04-22 21:02 [PATCH 0/7] New options to control how Python is initialized Andrew Burgess
2021-04-22 21:02 ` [PATCH 1/7] gdb: remove unused argument from gdb_init Andrew Burgess
@ 2021-04-22 21:02 ` Andrew Burgess
2021-04-23 14:16 ` Tom Tromey
2021-04-22 21:02 ` [PATCH 3/7] gdb: delay python initialisation until gdbpy_finish_initialization Andrew Burgess
` (4 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Andrew Burgess @ 2021-04-22 21:02 UTC (permalink / raw)
To: gdb-patches
In order for our SIGINT handling to work correctly with Python we
require that SIGINT be set to SIG_DFL during Python's initialisation.
Currently this is the case, but, in a later commit I plan to delay the
initialisation of Python until after the point where GDB's own SIGINT
handler has been installed.
The consequence of this is that our SIGINT handling would become
broken.
In this commit I propose adding an RAII class that will ensure SIGINT
is set to SIG_DFL during the call to each extension languages
finish_initialization method.
At this point this change should have not effect.
gdb/ChangeLog:
* extension.c (struct scoped_default_signal): New struct.
(scoped_default_sigint): New typedef.
(finish_ext_lang_initialization): Make use of
scoped_default_sigint.
---
gdb/ChangeLog | 7 +++++++
gdb/extension.c | 28 +++++++++++++++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/gdb/extension.c b/gdb/extension.c
index 0e0d42685fc..8f3722d3049 100644
--- a/gdb/extension.c
+++ b/gdb/extension.c
@@ -296,6 +296,29 @@ ext_lang_auto_load_enabled (const struct extension_language_defn *extlang)
return extlang->script_ops->auto_load_enabled (extlang);
}
\f
+
+/* RAII class used to temporarily return SIG to its default handler. */
+
+template<int SIG>
+struct scoped_default_signal
+{
+ scoped_default_signal ()
+ { m_old_sig_handler = signal (SIG, SIG_DFL); }
+
+ ~scoped_default_signal ()
+ { signal (SIG, m_old_sig_handler); }
+
+ DISABLE_COPY_AND_ASSIGN (scoped_default_signal);
+
+private:
+ /* The previous signal handler that needs to be restored. */
+ sighandler_t m_old_sig_handler;
+};
+
+/* Class to temporarily return SIGINT to its default handler. */
+
+using scoped_default_sigint = scoped_default_signal<SIGINT>;
+
/* Functions that iterate over all extension languages.
These only iterate over external extension languages, not including
GDB's own extension/scripting language, unless otherwise indicated. */
@@ -310,7 +333,10 @@ finish_ext_lang_initialization (void)
{
if (extlang->ops != nullptr
&& extlang->ops->finish_initialization != NULL)
- extlang->ops->finish_initialization (extlang);
+ {
+ scoped_default_sigint set_sigint_to_default_handler;
+ extlang->ops->finish_initialization (extlang);
+ }
}
}
--
2.25.4
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 3/7] gdb: delay python initialisation until gdbpy_finish_initialization
2021-04-22 21:02 [PATCH 0/7] New options to control how Python is initialized Andrew Burgess
2021-04-22 21:02 ` [PATCH 1/7] gdb: remove unused argument from gdb_init Andrew Burgess
2021-04-22 21:02 ` [PATCH 2/7] gdb: ensure SIGINT is set to SIG_DFL during initialisation Andrew Burgess
@ 2021-04-22 21:02 ` Andrew Burgess
2021-04-23 14:26 ` Tom Tromey
2021-04-22 21:02 ` [PATCH 4/7] gdb delay guile initialization until gdbscm_finish_initialization Andrew Burgess
` (3 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Andrew Burgess @ 2021-04-22 21:02 UTC (permalink / raw)
To: gdb-patches
Delay Python initialisation until gdbpy_finish_initialization.
This is mostly about splitting the existing gdbpy_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbpy_initialize_*
functions.
Then the call to do_start_initialization (in python/python.c) is moved
from the _initialize_python function into gdbpy_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/py-arch.c (_initialize_py_arch): New function.
(gdbpy_initialize_arch): Move code to _initialize_py_arch.
* python/py-block.c (_initialize_py_block): New function.
(gdbpy_initialize_blocks): Move code to _initialize_py_block.
* python/py-inferior.c (_initialize_py_inferior): New function.
(gdbpy_initialize_inferior): Move code to _initialize_py_inferior.
* python/py-objfile.c (_initialize_py_objfile): New function.
(gdbpy_initialize_objfile): Move code to _initialize_py_objfile.
* python/py-progspace.c (_initialize_py_progspace): New function.
(gdbpy_initialize_pspace): Move code to _initialize_py_progspace.
* python/py-registers.c (_initialize_py_registers): New function.
(gdbpy_initialize_registers): Move code to
_initialize_py_registers.
* python/py-symbol.c (_initialize_py_symbol): New function.
(gdbpy_initialize_symbols): Move code to _initialize_py_symbol.
* python/py-symtab.c (_initialize_py_symtab): New function.
(gdbpy_initialize_symtabs): Move code to _initialize_py_symtab.
* python/py-type.c (_initialize_py_type): New function.
(gdbpy_initialize_types): Move code to _initialize_py_type.
* python/py-unwind.c (_initialize_py_unwind): New function.
(gdbpy_initialize_unwind): Move code to _initialize_py_unwind.
* python/python.c (_initialize_python): Move call to
do_start_initialization to gdbpy_finish_initialization.
(gdbpy_finish_initialization): Add call to
do_start_initialization.
---
gdb/ChangeLog | 28 ++++++++++++++++++++++++++++
gdb/python/py-arch.c | 8 +++++++-
gdb/python/py-block.c | 17 +++++++++++------
gdb/python/py-inferior.c | 11 ++++++++---
gdb/python/py-objfile.c | 9 +++++++--
gdb/python/py-progspace.c | 9 +++++++--
gdb/python/py-registers.c | 11 ++++++++---
gdb/python/py-symbol.c | 15 ++++++++++-----
gdb/python/py-symtab.c | 23 ++++++++++++++---------
gdb/python/py-type.c | 11 ++++++++---
gdb/python/py-unwind.c | 23 ++++++++++++++---------
gdb/python/python.c | 8 +++-----
12 files changed, 125 insertions(+), 48 deletions(-)
diff --git a/gdb/python/py-arch.c b/gdb/python/py-arch.c
index d1960b4906e..66f2d28b94a 100644
--- a/gdb/python/py-arch.c
+++ b/gdb/python/py-arch.c
@@ -271,12 +271,18 @@ archpy_register_groups (PyObject *self, PyObject *args)
return gdbpy_new_reggroup_iterator (gdbarch);
}
+void _initialize_py_arch ();
+void
+_initialize_py_arch ()
+{
+ arch_object_data = gdbarch_data_register_post_init (arch_object_data_init);
+}
+
/* Initializes the Architecture class in the gdb module. */
int
gdbpy_initialize_arch (void)
{
- arch_object_data = gdbarch_data_register_post_init (arch_object_data_init);
arch_object_type.tp_new = PyType_GenericNew;
if (PyType_Ready (&arch_object_type) < 0)
return -1;
diff --git a/gdb/python/py-block.c b/gdb/python/py-block.c
index d257545b8aa..244ff9a6bab 100644
--- a/gdb/python/py-block.c
+++ b/gdb/python/py-block.c
@@ -427,6 +427,17 @@ del_objfile_blocks (struct objfile *objfile, void *datum)
}
}
+void _initialize_py_block ();
+void
+_initialize_py_block ()
+{
+ /* Register an objfile "free" callback so we can properly
+ invalidate blocks when an object file is about to be
+ deleted. */
+ blpy_objfile_data_key
+ = register_objfile_data_with_cleanup (NULL, del_objfile_blocks);
+}
+
int
gdbpy_initialize_blocks (void)
{
@@ -438,12 +449,6 @@ gdbpy_initialize_blocks (void)
if (PyType_Ready (&block_syms_iterator_object_type) < 0)
return -1;
- /* Register an objfile "free" callback so we can properly
- invalidate blocks when an object file is about to be
- deleted. */
- blpy_objfile_data_key
- = register_objfile_data_with_cleanup (NULL, del_objfile_blocks);
-
if (gdb_pymodule_addobject (gdb_module, "Block",
(PyObject *) &block_object_type) < 0)
return -1;
diff --git a/gdb/python/py-inferior.c b/gdb/python/py-inferior.c
index a3d5952a10b..3b6c99f3f58 100644
--- a/gdb/python/py-inferior.c
+++ b/gdb/python/py-inferior.c
@@ -891,6 +891,14 @@ gdbpy_selected_inferior (PyObject *self, PyObject *args)
inferior_to_inferior_object (current_inferior ()).release ());
}
+void _initialize_py_inferior ();
+void
+_initialize_py_inferior ()
+{
+ infpy_inf_data_key =
+ register_inferior_data_with_cleanup (NULL, py_free_inferior);
+}
+
int
gdbpy_initialize_inferior (void)
{
@@ -901,9 +909,6 @@ gdbpy_initialize_inferior (void)
(PyObject *) &inferior_object_type) < 0)
return -1;
- infpy_inf_data_key =
- register_inferior_data_with_cleanup (NULL, py_free_inferior);
-
gdb::observers::new_thread.attach (add_thread_object);
gdb::observers::thread_exit.attach (delete_thread_object);
gdb::observers::normal_stop.attach (python_on_normal_stop);
diff --git a/gdb/python/py-objfile.c b/gdb/python/py-objfile.c
index 8fb73820bb5..626f2d3e18c 100644
--- a/gdb/python/py-objfile.c
+++ b/gdb/python/py-objfile.c
@@ -693,12 +693,17 @@ objfile_to_objfile_object (struct objfile *objfile)
return gdbpy_ref<>::new_reference (result);
}
-int
-gdbpy_initialize_objfile (void)
+void _initialize_py_objfile ();
+void
+_initialize_py_objfile ()
{
objfpy_objfile_data_key
= register_objfile_data_with_cleanup (NULL, py_free_objfile);
+}
+int
+gdbpy_initialize_objfile (void)
+{
if (PyType_Ready (&objfile_object_type) < 0)
return -1;
diff --git a/gdb/python/py-progspace.c b/gdb/python/py-progspace.c
index 011c6cc6c36..d8df9c31d80 100644
--- a/gdb/python/py-progspace.c
+++ b/gdb/python/py-progspace.c
@@ -504,12 +504,17 @@ pspace_to_pspace_object (struct program_space *pspace)
return gdbpy_ref<>::new_reference (result);
}
-int
-gdbpy_initialize_pspace (void)
+void _initialize_py_progspace ();
+void
+_initialize_py_progspace ()
{
pspy_pspace_data_key
= register_program_space_data_with_cleanup (NULL, py_free_pspace);
+}
+int
+gdbpy_initialize_pspace (void)
+{
if (PyType_Ready (&pspace_object_type) < 0)
return -1;
diff --git a/gdb/python/py-registers.c b/gdb/python/py-registers.c
index eb59a499f33..04e554f48e1 100644
--- a/gdb/python/py-registers.c
+++ b/gdb/python/py-registers.c
@@ -423,14 +423,19 @@ gdbpy_parse_register_id (struct gdbarch *gdbarch, PyObject *pyo_reg_id,
return false;
}
+void _initialize_py_registers ();
+void
+_initialize_py_registers ()
+{
+ gdbpy_register_object_data
+ = gdbarch_data_register_post_init (gdbpy_register_object_data_init);
+}
+
/* Initializes the new Python classes from this file in the gdb module. */
int
gdbpy_initialize_registers ()
{
- gdbpy_register_object_data
- = gdbarch_data_register_post_init (gdbpy_register_object_data_init);
-
register_descriptor_object_type.tp_new = PyType_GenericNew;
if (PyType_Ready (®ister_descriptor_object_type) < 0)
return -1;
diff --git a/gdb/python/py-symbol.c b/gdb/python/py-symbol.c
index ead26d5d441..8953ee097cc 100644
--- a/gdb/python/py-symbol.c
+++ b/gdb/python/py-symbol.c
@@ -619,17 +619,22 @@ del_objfile_symbols (struct objfile *objfile, void *datum)
}
}
-int
-gdbpy_initialize_symbols (void)
+void _initialize_py_symbol ();
+void
+_initialize_py_symbol ()
{
- if (PyType_Ready (&symbol_object_type) < 0)
- return -1;
-
/* Register an objfile "free" callback so we can properly
invalidate symbol when an object file that is about to be
deleted. */
sympy_objfile_data_key
= register_objfile_data_with_cleanup (NULL, del_objfile_symbols);
+}
+
+int
+gdbpy_initialize_symbols (void)
+{
+ if (PyType_Ready (&symbol_object_type) < 0)
+ return -1;
if (PyModule_AddIntConstant (gdb_module, "SYMBOL_LOC_UNDEF", LOC_UNDEF) < 0
|| PyModule_AddIntConstant (gdb_module, "SYMBOL_LOC_CONST",
diff --git a/gdb/python/py-symtab.c b/gdb/python/py-symtab.c
index f0bf4ef5911..e9013731c4b 100644
--- a/gdb/python/py-symtab.c
+++ b/gdb/python/py-symtab.c
@@ -511,6 +511,20 @@ del_objfile_sal (struct objfile *objfile, void *datum)
}
}
+void _initialize_py_symtab ();
+void
+_initialize_py_symtab ()
+{
+ /* Register an objfile "free" callback so we can properly
+ invalidate symbol tables, and symbol table and line data
+ structures when an object file that is about to be
+ deleted. */
+ stpy_objfile_data_key
+ = register_objfile_data_with_cleanup (NULL, del_objfile_symtab);
+ salpy_objfile_data_key
+ = register_objfile_data_with_cleanup (NULL, del_objfile_sal);
+}
+
int
gdbpy_initialize_symtabs (void)
{
@@ -522,15 +536,6 @@ gdbpy_initialize_symtabs (void)
if (PyType_Ready (&sal_object_type) < 0)
return -1;
- /* Register an objfile "free" callback so we can properly
- invalidate symbol tables, and symbol table and line data
- structures when an object file that is about to be
- deleted. */
- stpy_objfile_data_key
- = register_objfile_data_with_cleanup (NULL, del_objfile_symtab);
- salpy_objfile_data_key
- = register_objfile_data_with_cleanup (NULL, del_objfile_sal);
-
if (gdb_pymodule_addobject (gdb_module, "Symtab",
(PyObject *) &symtab_object_type) < 0)
return -1;
diff --git a/gdb/python/py-type.c b/gdb/python/py-type.c
index bf707078841..3741fd26d1f 100644
--- a/gdb/python/py-type.c
+++ b/gdb/python/py-type.c
@@ -1417,14 +1417,19 @@ gdbpy_lookup_type (PyObject *self, PyObject *args, PyObject *kw)
return type_to_type_object (type);
}
+void _initialize_py_type ();
+void
+_initialize_py_type ()
+{
+ typy_objfile_data_key
+ = register_objfile_data_with_cleanup (save_objfile_types, NULL);
+}
+
int
gdbpy_initialize_types (void)
{
int i;
- typy_objfile_data_key
- = register_objfile_data_with_cleanup (save_objfile_types, NULL);
-
if (PyType_Ready (&type_object_type) < 0)
return -1;
if (PyType_Ready (&field_object_type) < 0)
diff --git a/gdb/python/py-unwind.c b/gdb/python/py-unwind.c
index f0574eba610..625b8902f5d 100644
--- a/gdb/python/py-unwind.c
+++ b/gdb/python/py-unwind.c
@@ -614,12 +614,10 @@ pyuw_on_new_gdbarch (struct gdbarch *newarch)
}
}
-/* Initialize unwind machinery. */
-
-int
-gdbpy_initialize_unwind (void)
+void _initialize_py_unwind ();
+void
+_initialize_py_unwind ()
{
- int rc;
add_setshow_zuinteger_cmd
("py-unwind", class_maintenance, &pyuw_debug,
_("Set Python unwinder debugging."),
@@ -629,14 +627,21 @@ gdbpy_initialize_unwind (void)
NULL,
&setdebuglist, &showdebuglist);
pyuw_gdbarch_data
- = gdbarch_data_register_post_init (pyuw_gdbarch_data_init);
+ = gdbarch_data_register_post_init (pyuw_gdbarch_data_init);
+}
+
+/* Initialize unwind machinery. */
+
+int
+gdbpy_initialize_unwind (void)
+{
gdb::observers::architecture_changed.attach (pyuw_on_new_gdbarch);
if (PyType_Ready (&pending_frame_object_type) < 0)
return -1;
- rc = gdb_pymodule_addobject (gdb_module, "PendingFrame",
- (PyObject *) &pending_frame_object_type);
- if (rc)
+ int rc = gdb_pymodule_addobject (gdb_module, "PendingFrame",
+ (PyObject *) &pending_frame_object_type);
+ if (rc != 0)
return rc;
if (PyType_Ready (&unwind_info_object_type) < 0)
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 9eed258c181..520508043ba 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -1881,11 +1881,6 @@ message == an error message without a stack will be printed."),
NULL, NULL,
&user_set_python_list,
&user_show_python_list);
-
-#ifdef HAVE_PYTHON
- if (!do_start_initialization () && PyErr_Occurred ())
- gdbpy_print_stack ();
-#endif /* HAVE_PYTHON */
}
#ifdef HAVE_PYTHON
@@ -1962,6 +1957,9 @@ do_finish_initialization (const struct extension_language_defn *extlang)
static void
gdbpy_finish_initialization (const struct extension_language_defn *extlang)
{
+ if (!do_start_initialization () && PyErr_Occurred ())
+ gdbpy_print_stack ();
+
gdbpy_enter enter_py (get_current_arch (), current_language);
if (!do_finish_initialization (extlang))
--
2.25.4
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/7] gdb: delay python initialisation until gdbpy_finish_initialization
2021-04-22 21:02 ` [PATCH 3/7] gdb: delay python initialisation until gdbpy_finish_initialization Andrew Burgess
@ 2021-04-23 14:26 ` Tom Tromey
0 siblings, 0 replies; 24+ messages in thread
From: Tom Tromey @ 2021-04-23 14:26 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
Andrew> Delay Python initialisation until gdbpy_finish_initialization.
Andrew> This is mostly about splitting the existing gdbpy_initialize_*
Andrew> functions in two, all the calls to register_objfile_data_with_cleanup,
Andrew> gdbarch_data_register_post_init, etc are moved into new _initialize_*
Andrew> functions, but everything else is left in the gdbpy_initialize_*
Andrew> functions.
Andrew> Then the call to do_start_initialization (in python/python.c) is moved
Andrew> from the _initialize_python function into gdbpy_finish_initialization.
Looks good, thank you.
Tom
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 4/7] gdb delay guile initialization until gdbscm_finish_initialization
2021-04-22 21:02 [PATCH 0/7] New options to control how Python is initialized Andrew Burgess
` (2 preceding siblings ...)
2021-04-22 21:02 ` [PATCH 3/7] gdb: delay python initialisation until gdbpy_finish_initialization Andrew Burgess
@ 2021-04-22 21:02 ` Andrew Burgess
2021-04-23 14:29 ` Tom Tromey
2021-04-22 21:02 ` [PATCH 5/7] gdb: initialise extension languages after processing early startup files Andrew Burgess
` (2 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Andrew Burgess @ 2021-04-22 21:02 UTC (permalink / raw)
To: gdb-patches
Like with the previous commit, this commit delays the initialisation
of the guile extension language until gdbscm_finish_initialization.
This is mostly about splitting the existing gdbscm_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbscm_initialize_*
functions.
Then the call to code previously in _initialize_guile is moved into
gdbscm_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* guile/guile.c (gdbscm_set_backtrace): Add declaration.
(gdbscm_finish_initialization): Add code moved from
_initialize_guile.
(_initialize_guile): Move code to gdbscm_finish_initialization.
* guile/scm-arch.c (gdbscm_initialize_arches): Move some code into
_initialize_scm_arch.
(_initialize_scm_arch): New function.
* guile/scm-block.c (gdbscm_initialize_blocks): Move some code
into _initialize_scm_block.
(_initialize_scm_block): New function.
* guile/scm-frame.c (gdbscm_initialize_frames): Move some code
into _initialize_scm_frame.
(_initialize_scm_frame): New function.
* guile/scm-objfile.c (gdbscm_initialize_objfiles): Move some code
into _initialize_scm_objfile.
(_initialize_scm_objfile): New function.
* guile/scm-progspace.c (gdbscm_initialize_pspaces): Move some
code into _initialize_scm_progspace.
(_initialize_scm_progspace): New function.
* guile/scm-symbol.c (gdbscm_initialize_symbols): Move some code
into _initialize_scm_symbol.
(_initialize_scm_symbol): New function.
* guile/scm-symtab.c (gdbscm_initialize_symtabs): Move some code
into _initialize_scm_symtab.
(_initialize_scm_symtab): New function.
* guile/scm-type.c (gdbscm_initialize_types): Move some code into
_initialize_scm_type.
(_initialize_scm_type): New function.
---
gdb/ChangeLog | 31 ++++++++++++++++
gdb/guile/guile.c | 74 ++++++++++++++++++---------------------
gdb/guile/scm-arch.c | 5 +++
gdb/guile/scm-block.c | 5 +++
gdb/guile/scm-frame.c | 5 +++
gdb/guile/scm-objfile.c | 5 +++
gdb/guile/scm-progspace.c | 5 +++
gdb/guile/scm-symbol.c | 5 +++
gdb/guile/scm-symtab.c | 5 +++
gdb/guile/scm-type.c | 11 ++++--
10 files changed, 109 insertions(+), 42 deletions(-)
diff --git a/gdb/guile/guile.c b/gdb/guile/guile.c
index 68c4532b390..9c2a40b61be 100644
--- a/gdb/guile/guile.c
+++ b/gdb/guile/guile.c
@@ -81,6 +81,7 @@ static int gdbscm_initialized (const struct extension_language_defn *);
static void gdbscm_eval_from_control_command
(const struct extension_language_defn *, struct command_line *);
static script_sourcer_func gdbscm_source_script;
+static void gdbscm_set_backtrace (int enable);
int gdb_scheme_initialized;
@@ -644,6 +645,40 @@ call_initialize_gdb_module (void *data)
static void
gdbscm_finish_initialization (const struct extension_language_defn *extlang)
{
+#if HAVE_GUILE
+ /* The Python support puts the C side in module "_gdb", leaving the
+ Python side to define module "gdb" which imports "_gdb". There is
+ evidently no similar convention in Guile so we skip this. */
+
+#if HAVE_GUILE_MANUAL_FINALIZATION
+ /* Our SMOB free functions are not thread-safe, as GDB itself is not
+ intended to be thread-safe. Disable automatic finalization so that
+ finalizers aren't run in other threads. */
+ scm_set_automatic_finalization_enabled (0);
+#endif
+
+ /* Before we initialize Guile, block signals needed by gdb (especially
+ SIGCHLD). This is done so that all threads created during Guile
+ initialization have SIGCHLD blocked. PR 17247. Really libgc and
+ Guile should do this, but we need to work with libgc 7.4.x. */
+ {
+ gdb::block_signals blocker;
+
+ /* scm_with_guile is the most portable way to initialize Guile. Plus
+ we need to initialize the Guile support while in Guile mode (e.g.,
+ called from within a call to scm_with_guile). */
+ scm_with_guile (call_initialize_gdb_module, NULL);
+ }
+
+ /* Set Guile's backtrace to match the "set guile print-stack" default.
+ [N.B. The two settings are still separate.] But only do this after
+ we've initialized Guile, it's nice to see a backtrace if there's an
+ error during initialization. OTOH, if the error is that gdb/init.scm
+ wasn't found because gdb is being run from the build tree, the
+ backtrace is more noise than signal. Sigh. */
+ gdbscm_set_backtrace (0);
+#endif
+
/* Restore the environment to the user interaction one. */
scm_set_current_module (scm_interaction_environment ());
}
@@ -770,43 +805,4 @@ void
_initialize_guile ()
{
install_gdb_commands ();
-
-#if HAVE_GUILE
- {
- /* The Python support puts the C side in module "_gdb", leaving the Python
- side to define module "gdb" which imports "_gdb". There is evidently no
- similar convention in Guile so we skip this. */
-
-#if HAVE_GUILE_MANUAL_FINALIZATION
- /* Our SMOB free functions are not thread-safe, as GDB itself is not
- intended to be thread-safe. Disable automatic finalization so that
- finalizers aren't run in other threads. */
- scm_set_automatic_finalization_enabled (0);
-#endif
-
- /* Before we initialize Guile, block signals needed by gdb
- (especially SIGCHLD).
- This is done so that all threads created during Guile initialization
- have SIGCHLD blocked. PR 17247.
- Really libgc and Guile should do this, but we need to work with
- libgc 7.4.x. */
- {
- gdb::block_signals blocker;
-
- /* scm_with_guile is the most portable way to initialize Guile.
- Plus we need to initialize the Guile support while in Guile mode
- (e.g., called from within a call to scm_with_guile). */
- scm_with_guile (call_initialize_gdb_module, NULL);
- }
-
- /* Set Guile's backtrace to match the "set guile print-stack" default.
- [N.B. The two settings are still separate.]
- But only do this after we've initialized Guile, it's nice to see a
- backtrace if there's an error during initialization.
- OTOH, if the error is that gdb/init.scm wasn't found because gdb is
- being run from the build tree, the backtrace is more noise than signal.
- Sigh. */
- gdbscm_set_backtrace (0);
- }
-#endif
}
diff --git a/gdb/guile/scm-arch.c b/gdb/guile/scm-arch.c
index f4f871d736e..863e5026b4c 100644
--- a/gdb/guile/scm-arch.c
+++ b/gdb/guile/scm-arch.c
@@ -650,7 +650,12 @@ gdbscm_initialize_arches (void)
scm_set_smob_print (arch_smob_tag, arscm_print_arch_smob);
gdbscm_define_functions (arch_functions, 1);
+}
+void _initialize_scm_arch ();
+void
+_initialize_scm_arch ()
+{
arch_object_data
= gdbarch_data_register_post_init (arscm_object_data_init);
}
diff --git a/gdb/guile/scm-block.c b/gdb/guile/scm-block.c
index 05263a4202b..e7a1083fdc9 100644
--- a/gdb/guile/scm-block.c
+++ b/gdb/guile/scm-block.c
@@ -799,7 +799,12 @@ gdbscm_initialize_blocks (void)
gdbscm_documentation_symbol,
gdbscm_scm_from_c_string ("\
Internal function to assist the block symbols iterator."));
+}
+void _initialize_scm_block ();
+void
+_initialize_scm_block ()
+{
/* Register an objfile "free" callback so we can properly
invalidate blocks when an object file is about to be deleted. */
bkscm_objfile_data_key
diff --git a/gdb/guile/scm-frame.c b/gdb/guile/scm-frame.c
index e932c2af7cd..9d5dfa698bc 100644
--- a/gdb/guile/scm-frame.c
+++ b/gdb/guile/scm-frame.c
@@ -1174,7 +1174,12 @@ gdbscm_initialize_frames (void)
gdbscm_define_functions (frame_functions, 1);
block_keyword = scm_from_latin1_keyword ("block");
+}
+void _initialize_scm_frame ();
+void
+_initialize_scm_frame ()
+{
/* Register an inferior "free" callback so we can properly
invalidate frames when an inferior file is about to be deleted. */
frscm_inferior_data_key
diff --git a/gdb/guile/scm-objfile.c b/gdb/guile/scm-objfile.c
index 44c5f2da06a..30e63f374e7 100644
--- a/gdb/guile/scm-objfile.c
+++ b/gdb/guile/scm-objfile.c
@@ -428,7 +428,12 @@ gdbscm_initialize_objfiles (void)
scm_set_smob_print (objfile_smob_tag, ofscm_print_objfile_smob);
gdbscm_define_functions (objfile_functions, 1);
+}
+void _initialize_scm_objfile ();
+void
+_initialize_scm_objfile ()
+{
ofscm_objfile_data_key
= register_objfile_data_with_cleanup (NULL, ofscm_handle_objfile_deleted);
}
diff --git a/gdb/guile/scm-progspace.c b/gdb/guile/scm-progspace.c
index 561a848beaa..d28dba9e3f7 100644
--- a/gdb/guile/scm-progspace.c
+++ b/gdb/guile/scm-progspace.c
@@ -417,7 +417,12 @@ gdbscm_initialize_pspaces (void)
scm_set_smob_print (pspace_smob_tag, psscm_print_pspace_smob);
gdbscm_define_functions (pspace_functions, 1);
+}
+void _initialize_scm_progspace ();
+void
+_initialize_scm_progspace ()
+{
psscm_pspace_data_key
= register_program_space_data_with_cleanup (NULL,
psscm_handle_pspace_deleted);
diff --git a/gdb/guile/scm-symbol.c b/gdb/guile/scm-symbol.c
index 3a60d1bc8a1..324f64a1492 100644
--- a/gdb/guile/scm-symbol.c
+++ b/gdb/guile/scm-symbol.c
@@ -817,7 +817,12 @@ gdbscm_initialize_symbols (void)
block_keyword = scm_from_latin1_keyword ("block");
domain_keyword = scm_from_latin1_keyword ("domain");
frame_keyword = scm_from_latin1_keyword ("frame");
+}
+void _initialize_scm_symbol ();
+void
+_initialize_scm_symbol ()
+{
/* Register an objfile "free" callback so we can properly
invalidate symbols when an object file is about to be deleted. */
syscm_objfile_data_key
diff --git a/gdb/guile/scm-symtab.c b/gdb/guile/scm-symtab.c
index 3f4b6764ac1..b4edcef8678 100644
--- a/gdb/guile/scm-symtab.c
+++ b/gdb/guile/scm-symtab.c
@@ -688,7 +688,12 @@ gdbscm_initialize_symtabs (void)
scm_set_smob_print (sal_smob_tag, stscm_print_sal_smob);
gdbscm_define_functions (symtab_functions, 1);
+}
+void _initialize_scm_symtab ();
+void
+_initialize_scm_symtab ()
+{
/* Register an objfile "free" callback so we can properly
invalidate symbol tables, and symbol table and line data
structures when an object file that is about to be deleted. */
diff --git a/gdb/guile/scm-type.c b/gdb/guile/scm-type.c
index dd45d8e8b35..b02a95870dc 100644
--- a/gdb/guile/scm-type.c
+++ b/gdb/guile/scm-type.c
@@ -1498,11 +1498,16 @@ Internal function to assist the type fields iterator."));
block_keyword = scm_from_latin1_keyword ("block");
+ global_types_map = gdbscm_create_eqable_gsmob_ptr_map (tyscm_hash_type_smob,
+ tyscm_eq_type_smob);
+}
+
+void _initialize_scm_type ();
+void
+_initialize_scm_type ()
+{
/* Register an objfile "free" callback so we can properly copy types
associated with the objfile when it's about to be deleted. */
tyscm_objfile_data_key
= register_objfile_data_with_cleanup (save_objfile_types, NULL);
-
- global_types_map = gdbscm_create_eqable_gsmob_ptr_map (tyscm_hash_type_smob,
- tyscm_eq_type_smob);
}
--
2.25.4
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 4/7] gdb delay guile initialization until gdbscm_finish_initialization
2021-04-22 21:02 ` [PATCH 4/7] gdb delay guile initialization until gdbscm_finish_initialization Andrew Burgess
@ 2021-04-23 14:29 ` Tom Tromey
0 siblings, 0 replies; 24+ messages in thread
From: Tom Tromey @ 2021-04-23 14:29 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
Andrew> Like with the previous commit, this commit delays the initialisation
Andrew> of the guile extension language until gdbscm_finish_initialization.
Andrew> This is mostly about splitting the existing gdbscm_initialize_*
Andrew> functions in two, all the calls to register_objfile_data_with_cleanup,
Andrew> gdbarch_data_register_post_init, etc are moved into new _initialize_*
Andrew> functions, but everything else is left in the gdbscm_initialize_*
Andrew> functions.
Andrew> Then the call to code previously in _initialize_guile is moved into
Andrew> gdbscm_finish_initialization.
Andrew> There should be no user visible changes after this commit.
Looks good, thank you.
Tom
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 5/7] gdb: initialise extension languages after processing early startup files
2021-04-22 21:02 [PATCH 0/7] New options to control how Python is initialized Andrew Burgess
` (3 preceding siblings ...)
2021-04-22 21:02 ` [PATCH 4/7] gdb delay guile initialization until gdbscm_finish_initialization Andrew Burgess
@ 2021-04-22 21:02 ` Andrew Burgess
2021-04-23 14:30 ` Tom Tromey
2021-04-22 21:02 ` [PATCH 6/7] gdb: extension languages finish_initialization to initialize Andrew Burgess
2021-04-22 21:02 ` [PATCH 7/7] gdb: startup commands to control Python extension language Andrew Burgess
6 siblings, 1 reply; 24+ messages in thread
From: Andrew Burgess @ 2021-04-22 21:02 UTC (permalink / raw)
To: gdb-patches
Now (thanks to the last few commits) all extension languages are
fully initialised in their finish_initialization method, this commit
delays the call to this method until after the early initialization
files have been processed.
Right now there's no benefit from doing this, but in a later commit I
plan to add new options for Python that will control how Python is
initialized.
With this commit in place, my next commits will allow the user to add
options to their early initialization file and alter how Python starts
up.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (captured_main_1): Add a call to
finish_ext_lang_initialization.
* top.c (gdb_init): Remove call to finish_ext_lang_initialization.
---
gdb/ChangeLog | 6 ++++++
gdb/main.c | 3 +++
gdb/top.c | 6 ------
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/gdb/main.c b/gdb/main.c
index 652e6f76fa0..2a1c3a4866f 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -1053,6 +1053,9 @@ captured_main_1 (struct captured_main_args *context)
execute_cmdargs (&cmdarg_vec, CMDARG_EARLYINIT_FILE,
CMDARG_EARLYINIT_COMMAND, &ret);
+ /* Finish initializing the extension languges. */
+ finish_ext_lang_initialization ();
+
/* Recheck if we're starting up quietly after processing the startup
scripts and commands. */
if (!quiet)
diff --git a/gdb/top.c b/gdb/top.c
index b58cd4facfc..a83d16bed15 100644
--- a/gdb/top.c
+++ b/gdb/top.c
@@ -2408,12 +2408,6 @@ gdb_init ()
set_language (language_c);
expected_language = current_language; /* Don't warn about the change. */
- /* Python initialization, for example, can require various commands to be
- installed. For example "info pretty-printer" needs the "info"
- prefix to be installed. Keep things simple and just do final
- script initialization here. */
- finish_ext_lang_initialization ();
-
/* Create $_gdb_major and $_gdb_minor convenience variables. */
init_gdb_version_vars ();
}
--
2.25.4
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 6/7] gdb: extension languages finish_initialization to initialize
2021-04-22 21:02 [PATCH 0/7] New options to control how Python is initialized Andrew Burgess
` (4 preceding siblings ...)
2021-04-22 21:02 ` [PATCH 5/7] gdb: initialise extension languages after processing early startup files Andrew Burgess
@ 2021-04-22 21:02 ` Andrew Burgess
2021-04-23 14:31 ` Tom Tromey
2021-04-22 21:02 ` [PATCH 7/7] gdb: startup commands to control Python extension language Andrew Burgess
6 siblings, 1 reply; 24+ messages in thread
From: Andrew Burgess @ 2021-04-22 21:02 UTC (permalink / raw)
To: gdb-patches
Now that both Python and Guile are fully initialized from their
respective finish_initialization methods, the "finish" in the method
name doesn't really make sense; initialization starts _and_ finishes
with that method.
As such, this commit renames finish_initialization to just initialize.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* extension-priv.h (struct extension_language_ops): Rename
'finish_initialization' to 'initialize'.
* extension.c (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this, update comment, and updated
the calls to reflect the change in struct extension_language_ops.
* extension.h (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this.
* guile/guile.c (gdbscm_finish_initialization): Renamed to...
(gdbscm_initialize): ...this, update comment at definition.
(guile_extension_ops): Update.
* main.c (captured_main_1): Update call to
finish_ext_lang_initialization.
* python/python.c (gdbpy_finish_initialization): Rename to...
(gdbpy_initialize): ...this, update comment at definition, and
update call to do_finish_initialization.
(python_extension_ops): Update.
(do_finish_initialization): Rename to...
(do_initialize): ...this, and update comment.
---
gdb/ChangeLog | 21 +++++++++++++++++++++
gdb/extension-priv.h | 9 +++++----
gdb/extension.c | 10 +++++-----
gdb/extension.h | 2 +-
gdb/guile/guile.c | 12 +++++-------
gdb/main.c | 4 ++--
gdb/python/python.c | 25 +++++++++++--------------
7 files changed, 50 insertions(+), 33 deletions(-)
diff --git a/gdb/extension-priv.h b/gdb/extension-priv.h
index 1b6701ba6cc..77f23e0f911 100644
--- a/gdb/extension-priv.h
+++ b/gdb/extension-priv.h
@@ -109,10 +109,11 @@ struct extension_language_script_ops
struct extension_language_ops
{
- /* Called at the end of gdb initialization to give the extension language
- an opportunity to finish up. This is useful for things like adding
- new commands where one has to wait until gdb itself is initialized. */
- void (*finish_initialization) (const struct extension_language_defn *);
+ /* Called after GDB has processed the early initialization settings
+ files. This is when the extension language should be initialized. By
+ the time this is called all of the earlier initialization functions
+ have already been called. */
+ void (*initialize) (const struct extension_language_defn *);
/* Return non-zero if the extension language successfully initialized.
This method is required. */
diff --git a/gdb/extension.c b/gdb/extension.c
index 8f3722d3049..920827c453f 100644
--- a/gdb/extension.c
+++ b/gdb/extension.c
@@ -323,19 +323,19 @@ using scoped_default_sigint = scoped_default_signal<SIGINT>;
These only iterate over external extension languages, not including
GDB's own extension/scripting language, unless otherwise indicated. */
-/* Wrapper to call the extension_language_ops.finish_initialization "method"
- for each compiled-in extension language. */
+/* Wrapper to call the extension_language_ops.initialize "method" for each
+ compiled-in extension language. */
void
-finish_ext_lang_initialization (void)
+ext_lang_initialization (void)
{
for (const struct extension_language_defn *extlang : extension_languages)
{
if (extlang->ops != nullptr
- && extlang->ops->finish_initialization != NULL)
+ && extlang->ops->initialize != NULL)
{
scoped_default_sigint set_sigint_to_default_handler;
- extlang->ops->finish_initialization (extlang);
+ extlang->ops->initialize (extlang);
}
}
}
diff --git a/gdb/extension.h b/gdb/extension.h
index a505c68d25e..56f57560de3 100644
--- a/gdb/extension.h
+++ b/gdb/extension.h
@@ -276,7 +276,7 @@ extern bool ext_lang_auto_load_enabled (const struct extension_language_defn *);
/* Wrappers for each extension language API function that iterate over all
extension languages. */
-extern void finish_ext_lang_initialization (void);
+extern void ext_lang_initialization (void);
extern void eval_ext_lang_from_control_command (struct command_line *cmd);
diff --git a/gdb/guile/guile.c b/gdb/guile/guile.c
index 9c2a40b61be..bdf15cd498b 100644
--- a/gdb/guile/guile.c
+++ b/gdb/guile/guile.c
@@ -75,8 +75,7 @@ const char *gdbscm_print_excp = gdbscm_print_excp_message;
\f
#ifdef HAVE_GUILE
-static void gdbscm_finish_initialization
- (const struct extension_language_defn *);
+static void gdbscm_initialize (const struct extension_language_defn *);
static int gdbscm_initialized (const struct extension_language_defn *);
static void gdbscm_eval_from_control_command
(const struct extension_language_defn *, struct command_line *);
@@ -113,7 +112,7 @@ static const struct extension_language_script_ops guile_extension_script_ops =
static const struct extension_language_ops guile_extension_ops =
{
- gdbscm_finish_initialization,
+ gdbscm_initialize,
gdbscm_initialized,
gdbscm_eval_from_control_command,
@@ -638,12 +637,11 @@ call_initialize_gdb_module (void *data)
return NULL;
}
-/* A callback to finish Guile initialization after gdb has finished all its
- initialization.
- This is the extension_language_ops.finish_initialization "method". */
+/* A callback to initialize Guile after gdb has finished all its
+ initialization. This is the extension_language_ops.initialize "method". */
static void
-gdbscm_finish_initialization (const struct extension_language_defn *extlang)
+gdbscm_initialize (const struct extension_language_defn *extlang)
{
#if HAVE_GUILE
/* The Python support puts the C side in module "_gdb", leaving the
diff --git a/gdb/main.c b/gdb/main.c
index 2a1c3a4866f..d92aa02d831 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -1053,8 +1053,8 @@ captured_main_1 (struct captured_main_args *context)
execute_cmdargs (&cmdarg_vec, CMDARG_EARLYINIT_FILE,
CMDARG_EARLYINIT_COMMAND, &ret);
- /* Finish initializing the extension languges. */
- finish_ext_lang_initialization ();
+ /* Initialize the extension languages. */
+ ext_lang_initialization ();
/* Recheck if we're starting up quietly after processing the startup
scripts and commands. */
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 520508043ba..1d0d86d5c49 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -129,8 +129,7 @@ PyObject *gdbpy_gdb_memory_error;
static script_sourcer_func gdbpy_source_script;
static objfile_script_sourcer_func gdbpy_source_objfile_script;
static objfile_script_executor_func gdbpy_execute_objfile_script;
-static void gdbpy_finish_initialization
- (const struct extension_language_defn *);
+static void gdbpy_initialize (const struct extension_language_defn *);
static int gdbpy_initialized (const struct extension_language_defn *);
static void gdbpy_eval_from_control_command
(const struct extension_language_defn *, struct command_line *cmd);
@@ -162,7 +161,7 @@ const struct extension_language_script_ops python_extension_script_ops =
const struct extension_language_ops python_extension_ops =
{
- gdbpy_finish_initialization,
+ gdbpy_initialize,
gdbpy_initialized,
gdbpy_eval_from_control_command,
@@ -1885,12 +1884,12 @@ message == an error message without a stack will be printed."),
#ifdef HAVE_PYTHON
-/* Helper function for gdbpy_finish_initialization. This does the
- work and then returns false if an error has occurred and must be
- displayed, or true on success. */
+/* Helper function for gdbpy_initialize. This does the work and then
+ returns false if an error has occurred and must be displayed, or true on
+ success. */
static bool
-do_finish_initialization (const struct extension_language_defn *extlang)
+do_initialize (const struct extension_language_defn *extlang)
{
PyObject *m;
PyObject *sys_path;
@@ -1948,21 +1947,19 @@ do_finish_initialization (const struct extension_language_defn *extlang)
return gdb_pymodule_addobject (m, "gdb", gdb_python_module) >= 0;
}
-/* Perform the remaining python initializations.
- These must be done after GDB is at least mostly initialized.
- E.g., The "info pretty-printer" command needs the "info" prefix
- command installed.
- This is the extension_language_ops.finish_initialization "method". */
+/* Perform Python initialization. This will be called after GDB has
+ performed all of its own initialization. This is the
+ extension_language_ops.initialize "method". */
static void
-gdbpy_finish_initialization (const struct extension_language_defn *extlang)
+gdbpy_initialize (const struct extension_language_defn *extlang)
{
if (!do_start_initialization () && PyErr_Occurred ())
gdbpy_print_stack ();
gdbpy_enter enter_py (get_current_arch (), current_language);
- if (!do_finish_initialization (extlang))
+ if (!do_initialize (extlang))
{
gdbpy_print_stack ();
warning (_("internal error: Unhandled Python exception"));
--
2.25.4
^ permalink raw reply [flat|nested] 24+ messages in thread* [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-22 21:02 [PATCH 0/7] New options to control how Python is initialized Andrew Burgess
` (5 preceding siblings ...)
2021-04-22 21:02 ` [PATCH 6/7] gdb: extension languages finish_initialization to initialize Andrew Burgess
@ 2021-04-22 21:02 ` Andrew Burgess
2021-04-23 10:31 ` Eli Zaretskii
` (2 more replies)
6 siblings, 3 replies; 24+ messages in thread
From: Andrew Burgess @ 2021-04-22 21:02 UTC (permalink / raw)
To: gdb-patches
Add two new commands to GDB that can be placed into the early
initialization to control how Python starts up. The new options are:
set python ignore-environment on|off
set python dont-write-bytecode auto|on|off
show python ignore-environment
show python dont-write-bytecode
These can be used from GDB's startup file to control how the Python
extension language behaves. These options are equivalent to the -E
and -B flags to python respectively, their descriptions from the
Python man page:
-E Ignore environment variables like PYTHONPATH and PYTHONHOME
that modify the behavior of the interpreter.
-B Don't write .pyc files on import.
gdb/ChangeLog:
* NEWS: Mention new commands.
* python/python.c (python_ignore_environment): New static global.
(show_python_ignore_environment): New function.
(set_python_ignore_environment): New function.
(python_dont_write_bytecode): New static global.
(show_python_dont_write_bytecode): New function.
(set_python_dont_write_bytecode): New function.
(_initialize_python): Register new commands.
gdb/doc/ChangeLog:
* python.texinfo (Python Commands): Mention new commands.
gdb/testsuite/ChangeLog:
* gdb.python/py-startup-opt.exp: New file.
---
gdb/ChangeLog | 11 ++
gdb/NEWS | 16 +++
gdb/doc/ChangeLog | 4 +
gdb/doc/python.texi | 38 +++++++
gdb/python/python.c | 98 ++++++++++++++++
gdb/testsuite/ChangeLog | 4 +
gdb/testsuite/gdb.python/py-startup-opt.exp | 118 ++++++++++++++++++++
7 files changed, 289 insertions(+)
create mode 100644 gdb/testsuite/gdb.python/py-startup-opt.exp
diff --git a/gdb/NEWS b/gdb/NEWS
index faccf40dd41..a1b83ad9fce 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -101,6 +101,22 @@ show startup-quietly
initialization file (e.g. ~/.config/gdb/gdbearlyinit) in order to
affect GDB.
+set python ignore-environment on|off
+show python ignore-environment
+ When 'on', this causes GDB's builtin Python to ignore any
+ environment variables that would otherwise effect how Python
+ behaves. This command needs to be added to an early initialization
+ file (e.g. ~/.config/gdb/gdbearlyinit) in order to affect GDB.
+
+set python dont-write-bytecode auto|on|off
+show python dont-write-bytecode
+ When 'on', this causes GDB's builtin Python to not write any
+ byte-code (.pyc files) to disk. This command needs to be added to
+ an early initialization file (e.g. ~/.config/gdb/gdbearlyinit) in
+ order to affect GDB. When 'off' byte-code will always be written.
+ When set to 'auto' (the default) Python will check the
+ PYTHONDONTWRITEBYTECODE. environment variable.
+
* Changed commands
break [PROBE_MODIFIER] [LOCATION] [thread THREADNUM]
diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 9135d415dd1..aa5dc55bb60 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -103,6 +103,44 @@
full Python stack printing is enabled; if @code{none}, then Python stack
and message printing is disabled; if @code{message}, the default, only
the message component of the error is printed.
+
+@kindex set python ignore-environment
+@item set python ignore-environment @r{[}on@r{|}off@r{]}
+By default this option is @samp{off}, and, when @value{GDBN}
+initializes its internal Python interpreter, the Python interpreter
+will check the environment for variables that will effect how it
+behaves, for example @samp{PYTHONHOME}, and
+@samp{PYTHONPATH}@footnote{See the ENVIRONMENT VARIABLES section of
+@code{man 1 python} for a comprehensive list.}.
+
+If this option is set to @samp{on} before Python is initialized then
+Python will ignore all such environment variables. As Python is
+initialized early during @value{GDBN}'s startup process, then this
+option must be placed into the early initialization file
+(@pxref{Initialization Files}) to have the desired effect.
+
+This option is equivalent to passing @samp{-E} to the real
+@samp{python} executable.
+
+@kindex set python dont-write-bytecode
+@item set python dont-write-bytecode @r{[}auto@r{|}on@r{|}off@r{]}
+When this option is @samp{off}, then, once @value{GDBN} has
+initialized the Python interpreter, the interpreter will byte-compile
+any Python modules that it imports and write the byte code to disk in
+@code{.pyc} files.
+
+If this option is set to @samp{on} before Python is initialized then
+Python will no longer write the byte code to disk. As Python is
+initialized early during @value{GDBN}'s startup process, then this
+option must be placed into the early initialization file
+(@pxref{Initialization Files}) to have the desired effect.
+
+By default this option is set to @samp{auto}, in this mode Python will
+check the environment variable @samp{PYTHONDONTWRITEBYTECODE} to see
+if it should write out byte-code or not.
+
+This option is equivalent to passing @samp{-B} to the real
+@samp{python} executable.
@end table
It is also possible to execute a Python script from the @value{GDBN}
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 1d0d86d5c49..c46d68b73ed 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -1578,6 +1578,80 @@ python_command (const char *arg, int from_tty)
#endif /* HAVE_PYTHON */
+/* When this is turned on before Python is initialised then Python will
+ ignore any environment variables related to Python. This is equivalent
+ to passing `-E' to the python program. */
+static bool python_ignore_environment = false;
+
+/* Implement 'show python ignore-environment'. */
+
+static void
+show_python_ignore_environment (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ fprintf_filtered (file, _("Python's ignore-environment setting is %s.\n"),
+ value);
+}
+
+/* Implement 'set python ignore-environment'. This sets Python's internal
+ flag no matter when the command is issued, however, if this is used
+ after Py_Initialize has been called then most of the environment will
+ already have been read. */
+
+static void
+set_python_ignore_environment (const char *args, int from_tty,
+ struct cmd_list_element *c)
+{
+#ifdef HAVE_PYTHON
+ Py_IgnoreEnvironmentFlag = python_ignore_environment ? 1 : 0;
+#endif
+}
+
+/* When this is turned on before Python is initialised then Python will
+ not write `.pyc' files on import of a module. */
+static enum auto_boolean python_dont_write_bytecode = AUTO_BOOLEAN_AUTO;
+
+/* Implement 'show python dont-write-bytecode'. */
+
+static void
+show_python_dont_write_bytecode (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ if (python_dont_write_bytecode == AUTO_BOOLEAN_AUTO)
+ {
+ const char *auto_string
+ = (python_ignore_environment
+ || getenv ("PYTHONDONTWRITEBYTECODE") == nullptr) ? "off" : "on";
+
+ fprintf_filtered (file,
+ _("Python's dont-write-bytecode setting is %s (currently %s).\n"),
+ value, auto_string);
+ }
+ else
+ fprintf_filtered (file, _("Python's dont-write-bytecode setting is %s.\n"),
+ value);
+}
+
+/* Implement 'set python dont-write-bytecode'. This sets Python's internal
+ flag no matter when the command is issued, however, if this is used
+ after Py_Initialize has been called then many modules could already
+ have been imported and their byte code written out. */
+
+static void
+set_python_dont_write_bytecode (const char *args, int from_tty,
+ struct cmd_list_element *c)
+{
+#ifdef HAVE_PYTHON
+ if (python_dont_write_bytecode == AUTO_BOOLEAN_AUTO)
+ Py_DontWriteBytecodeFlag
+ = (!python_ignore_environment
+ && getenv ("PYTHONDONTWRITEBYTECODE") != nullptr) ? 1 : 0;
+ else
+ Py_DontWriteBytecodeFlag
+ = python_dont_write_bytecode == AUTO_BOOLEAN_TRUE ? 1 : 0;
+#endif /* HAVE_PYTHON */
+}
+
\f
/* Lists for 'set python' commands. */
@@ -1880,6 +1954,30 @@ message == an error message without a stack will be printed."),
NULL, NULL,
&user_set_python_list,
&user_show_python_list);
+
+ add_setshow_boolean_cmd ("ignore-environment", no_class,
+ &python_ignore_environment, _("\
+Set whether the Python interpreter should ignore environment variables."), _(" \
+Show whether the Python interpreter showlist ignore environment variables."), _(" \
+When enabled GDB's Python interpreter will ignore any Python related\n \
+flags in the environment. This is equivalent to passing `-E' to a\n \
+python executable."),
+ set_python_ignore_environment,
+ show_python_ignore_environment,
+ &user_set_python_list,
+ &user_show_python_list);
+
+ add_setshow_auto_boolean_cmd ("dont-write-bytecode", no_class,
+ &python_dont_write_bytecode, _("\
+Set whether the Python interpreter should ignore environment variables."), _(" \
+Show whether the Python interpreter showlist ignore environment variables."), _(" \
+When enabled GDB's Python interpreter will ignore any Python related\n \
+flags in the environment. This is equivalent to passing `-E' to a\n \
+python executable."),
+ set_python_dont_write_bytecode,
+ show_python_dont_write_bytecode,
+ &user_set_python_list,
+ &user_show_python_list);
}
#ifdef HAVE_PYTHON
diff --git a/gdb/testsuite/gdb.python/py-startup-opt.exp b/gdb/testsuite/gdb.python/py-startup-opt.exp
new file mode 100644
index 00000000000..842add30807
--- /dev/null
+++ b/gdb/testsuite/gdb.python/py-startup-opt.exp
@@ -0,0 +1,118 @@
+# Copyright 2021 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test the flags within GDB that can be used to control how Python is
+# initialized.
+
+gdb_start
+
+# Skip all tests if Python scripting is not enabled.
+if { [skip_python_tests] } { continue }
+
+gdb_exit
+
+# Return a list containing two directory paths for newly created home
+# directories.
+#
+# The first directory is a HOME style home directory, it contains a
+# .gdbearlyinit file containing CONTENT.
+#
+# The second directory is an XDG_CONFIG_HOME style home directory, it
+# contains a sub-directory gdb/, inside which is a file gdbearlyinit
+# that also contains CONTENT.
+#
+# The PREFIX is used in both directory names and should be unique for
+# each call to this function.
+proc setup_home_directories { prefix content } {
+ set home_dir [standard_output_file "${prefix}-home"]
+ set xdg_home_dir [standard_output_file "${prefix}-xdg"]
+
+ file mkdir $home_dir
+ file mkdir "$xdg_home_dir/gdb"
+
+ # Write the content into the HOME directory.
+ set fd [open "$home_dir/.gdbearlyinit" w]
+ puts $fd $content
+ close $fd
+
+ # Copy this from the HOME directory into the XDG_CONFIG_HOME
+ # directory.
+ file copy -force "$home_dir/.gdbearlyinit" "$xdg_home_dir/gdb/gdbearlyinit"
+
+ return [list $home_dir $xdg_home_dir]
+}
+
+# Start GDB and check the status of the Python system flags that we
+# can control from within GDB.
+proc test_python_settings { exp_state } {
+ gdb_start
+
+ gdb_test_no_output "python import sys"
+
+ foreach_with_prefix attr {ignore_environment dont_write_bytecode} {
+ gdb_test_multiline "testname" \
+ "python" "" \
+ "if hasattr(sys, 'flags') and getattr(sys.flags, '${attr}', False):" "" \
+ " print (\"${attr} is on\")" "" \
+ "else:" "" \
+ " print (\"${attr} is off\")" "" \
+ "end" "${attr} is ${exp_state}"
+ }
+
+ gdb_exit
+}
+
+save_vars { env(TERM) } {
+ # We need an ANSI-capable terminal to get the output.
+ setenv TERM ansi
+
+ # Check the features are off by default.
+ test_python_settings "off"
+
+ # Create an empty directory we can use as HOME for some of the
+ # tests below. When we set XDG_CONFIG_HOME we still need to point
+ # HOME at something otherwise GDB complains that it doesn't know
+ # where to create the index cache.
+ set empty_home_dir [standard_output_file fake-empty-home]
+
+ # Create two directories to use for the style setting test.
+ set dirs [setup_home_directories "style" \
+ [multi_line_input \
+ "set python dont-write-bytecode on" \
+ "set python ignore-environment on"]]
+ set home_dir [lindex $dirs 0]
+ set xdg_home_dir [lindex $dirs 1]
+
+ # Now arrange to use the fake home directory early init file.
+ save_vars { INTERNAL_GDBFLAGS env(HOME) env(XDG_CONFIG_HOME) } {
+ set INTERNAL_GDBFLAGS [string map {"-nx" ""} $INTERNAL_GDBFLAGS]
+
+ with_test_prefix "using HOME config" {
+ # Now test GDB when using the HOME directory.
+ set env(HOME) $home_dir
+ unset -nocomplain env(XDG_CONFIG_HOME)
+ test_python_settings "on"
+ }
+
+ with_test_prefix "using XDG_CONFIG_HOME config" {
+ # Now test using the XDG_CONFIG_HOME folder. We still need to
+ # have a HOME directory set otherwise GDB will issue an error
+ # about not knowing where to place the index cache.
+ set env(XDG_CONFIG_HOME) $xdg_home_dir
+ set env(HOME) $empty_home_dir
+ test_python_settings "on"
+ }
+ }
+}
--
2.25.4
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-22 21:02 ` [PATCH 7/7] gdb: startup commands to control Python extension language Andrew Burgess
@ 2021-04-23 10:31 ` Eli Zaretskii
2021-04-23 14:32 ` Tom Tromey
2021-04-29 8:32 ` Tom de Vries
2 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2021-04-23 10:31 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
> From: Andrew Burgess <andrew.burgess@embecosm.com>
> Date: Thu, 22 Apr 2021 22:02:48 +0100
>
> gdb/ChangeLog:
>
> * NEWS: Mention new commands.
> * python/python.c (python_ignore_environment): New static global.
> (show_python_ignore_environment): New function.
> (set_python_ignore_environment): New function.
> (python_dont_write_bytecode): New static global.
> (show_python_dont_write_bytecode): New function.
> (set_python_dont_write_bytecode): New function.
> (_initialize_python): Register new commands.
>
> gdb/doc/ChangeLog:
>
> * python.texinfo (Python Commands): Mention new commands.
>
> gdb/testsuite/ChangeLog:
>
> * gdb.python/py-startup-opt.exp: New file.
Thanks. The documentation parts are approved, provided that the few
minor nits below are taken care of.
> +@kindex set python ignore-environment
> +@item set python ignore-environment @r{[}on@r{|}off@r{]}
> +By default this option is @samp{off}, and, when @value{GDBN}
> +initializes its internal Python interpreter, the Python interpreter
> +will check the environment for variables that will effect how it
> +behaves, for example @samp{PYTHONHOME}, and
> +@samp{PYTHONPATH}@footnote{See the ENVIRONMENT VARIABLES section of
> +@code{man 1 python} for a comprehensive list.}.
Please use @env as markup for environment variables, not @samp.
> +This option is equivalent to passing @samp{-E} to the real
^^^^^^^^^
@option{-E}
> +@samp{python} executable.
^^^^^^^^^^^^^
@command{python}
> +@kindex set python dont-write-bytecode
> +@item set python dont-write-bytecode @r{[}auto@r{|}on@r{|}off@r{]}
> +When this option is @samp{off}, then, once @value{GDBN} has
> +initialized the Python interpreter, the interpreter will byte-compile
> +any Python modules that it imports and write the byte code to disk in
> +@code{.pyc} files.
^^^^^^^^^^^
@file{*.pyc}
> +By default this option is set to @samp{auto}, in this mode Python will
> +check the environment variable @samp{PYTHONDONTWRITEBYTECODE} to see
^^^^^
@env
> +This option is equivalent to passing @samp{-B} to the real
> +@samp{python} executable.
@option and @command, as before.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-22 21:02 ` [PATCH 7/7] gdb: startup commands to control Python extension language Andrew Burgess
2021-04-23 10:31 ` Eli Zaretskii
@ 2021-04-23 14:32 ` Tom Tromey
2021-04-29 8:32 ` Tom de Vries
2 siblings, 0 replies; 24+ messages in thread
From: Tom Tromey @ 2021-04-23 14:32 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
Andrew> gdb/ChangeLog:
Andrew> * NEWS: Mention new commands.
Andrew> * python/python.c (python_ignore_environment): New static global.
Andrew> (show_python_ignore_environment): New function.
Andrew> (set_python_ignore_environment): New function.
Andrew> (python_dont_write_bytecode): New static global.
Andrew> (show_python_dont_write_bytecode): New function.
Andrew> (set_python_dont_write_bytecode): New function.
Andrew> (_initialize_python): Register new commands.
I think this probably fixes PR python/22503.
Other than that it looks good. Thanks for doing this.
Tom
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-22 21:02 ` [PATCH 7/7] gdb: startup commands to control Python extension language Andrew Burgess
2021-04-23 10:31 ` Eli Zaretskii
2021-04-23 14:32 ` Tom Tromey
@ 2021-04-29 8:32 ` Tom de Vries
2021-04-29 9:35 ` Andrew Burgess
2021-04-29 9:46 ` Andrew Burgess
2 siblings, 2 replies; 24+ messages in thread
From: Tom de Vries @ 2021-04-29 8:32 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
On 4/22/21 11:02 PM, Andrew Burgess wrote:
> +set python ignore-environment on|off
> +show python ignore-environment
> + When 'on', this causes GDB's builtin Python to ignore any
> + environment variables that would otherwise effect how Python
affect?
> + behaves. This command needs to be added to an early initialization
> + file (e.g. ~/.config/gdb/gdbearlyinit) in order to affect GDB.
> +
> +set python dont-write-bytecode auto|on|off
> +show python dont-write-bytecode
> + When 'on', this causes GDB's builtin Python to not write any
> + byte-code (.pyc files) to disk. This command needs to be added to
> + an early initialization file (e.g. ~/.config/gdb/gdbearlyinit) in
> + order to affect GDB. When 'off' byte-code will always be written.
> + When set to 'auto' (the default) Python will check the
> + PYTHONDONTWRITEBYTECODE. environment variable.
Dot at end of variable name.
> +
I ran into https://sourceware.org/bugzilla/show_bug.cgi?id=27788 due to
having PYTHONDONTWRITEBYTECODE set in my environment. My guess at this
point is that this is a test-case issue.
I played around a bit with the options and did:
...
$ echo $PYTHONDONTWRITEBYTECODE
1
$ gdb -q -batch \
-iex "set python ignore-environment on" \
-iex "show python dont-write-bytecode"
Python's dont-write-bytecode setting is auto (currently off).
$ gdb -q -batch \
-iex "set python ignore-environment off" \
-iex "show python dont-write-bytecode"
Python's dont-write-bytecode setting is auto (currently on).
...
which shows that there is an interaction between the two commands.
AFAICT, this is not evident from either the NEWS item, or the docs, and
I just wonder whether it's a good idea to make this explicit.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-29 8:32 ` Tom de Vries
@ 2021-04-29 9:35 ` Andrew Burgess
2021-04-29 9:46 ` Andrew Burgess
1 sibling, 0 replies; 24+ messages in thread
From: Andrew Burgess @ 2021-04-29 9:35 UTC (permalink / raw)
To: Tom de Vries; +Cc: gdb-patches
* Tom de Vries <tdevries@suse.de> [2021-04-29 10:32:05 +0200]:
> On 4/22/21 11:02 PM, Andrew Burgess wrote:
> > +set python ignore-environment on|off
> > +show python ignore-environment
> > + When 'on', this causes GDB's builtin Python to ignore any
> > + environment variables that would otherwise effect how Python
>
> affect?
>
> > + behaves. This command needs to be added to an early initialization
> > + file (e.g. ~/.config/gdb/gdbearlyinit) in order to affect GDB.
> > +
> > +set python dont-write-bytecode auto|on|off
> > +show python dont-write-bytecode
> > + When 'on', this causes GDB's builtin Python to not write any
> > + byte-code (.pyc files) to disk. This command needs to be added to
> > + an early initialization file (e.g. ~/.config/gdb/gdbearlyinit) in
> > + order to affect GDB. When 'off' byte-code will always be written.
> > + When set to 'auto' (the default) Python will check the
> > + PYTHONDONTWRITEBYTECODE. environment variable.
>
> Dot at end of variable name.
Thanks for pointing out these two issues, I pushed the patch below as
obvious to address them.
Thanks,
Andrew
---
commit 8eb82ba1fdc052d2bb08ec6f0d98b8d2c10edd17
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date: Thu Apr 29 10:29:41 2021 +0100
gdb/NEWS: Fix typo and stray full stop
Some errors introduced in commit:
commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9
Date: Thu Aug 27 16:53:13 2020 +0100
gdb: startup commands to control Python extension language
gdb/ChangeLog:
* NEWS: Fix typo and stray full stop.
diff --git a/gdb/NEWS b/gdb/NEWS
index 6550ea352ac..19cb444e7fe 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -109,7 +109,7 @@ show print type hex
set python ignore-environment on|off
show python ignore-environment
When 'on', this causes GDB's builtin Python to ignore any
- environment variables that would otherwise effect how Python
+ environment variables that would otherwise affect how Python
behaves. This command needs to be added to an early initialization
file (e.g. ~/.config/gdb/gdbearlyinit) in order to affect GDB.
@@ -120,7 +120,7 @@ show python dont-write-bytecode
an early initialization file (e.g. ~/.config/gdb/gdbearlyinit) in
order to affect GDB. When 'off' byte-code will always be written.
When set to 'auto' (the default) Python will check the
- PYTHONDONTWRITEBYTECODE. environment variable.
+ PYTHONDONTWRITEBYTECODE environment variable.
* Changed commands
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-29 8:32 ` Tom de Vries
2021-04-29 9:35 ` Andrew Burgess
@ 2021-04-29 9:46 ` Andrew Burgess
2021-04-29 10:08 ` Tom de Vries
2021-04-29 12:17 ` Eli Zaretskii
1 sibling, 2 replies; 24+ messages in thread
From: Andrew Burgess @ 2021-04-29 9:46 UTC (permalink / raw)
To: Tom de Vries; +Cc: gdb-patches
* Tom de Vries <tdevries@suse.de> [2021-04-29 10:32:05 +0200]:
> I ran into https://sourceware.org/bugzilla/show_bug.cgi?id=27788 due to
> having PYTHONDONTWRITEBYTECODE set in my environment. My guess at this
> point is that this is a test-case issue.
>
> I played around a bit with the options and did:
> ...
> $ echo $PYTHONDONTWRITEBYTECODE
> 1
>
> $ gdb -q -batch \
> -iex "set python ignore-environment on" \
> -iex "show python dont-write-bytecode"
> Python's dont-write-bytecode setting is auto (currently off).
>
> $ gdb -q -batch \
> -iex "set python ignore-environment off" \
> -iex "show python dont-write-bytecode"
> Python's dont-write-bytecode setting is auto (currently on).
> ...
> which shows that there is an interaction between the two commands.
> AFAICT, this is not evident from either the NEWS item, or the docs, and
> I just wonder whether it's a good idea to make this explicit.
Hi Tom,
Thanks for looking at this feature.
The docs for dont-write-bytecode say:
<snip>
By default this option is set to @samp{auto}, in this mode Python will
check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
if it should write out byte-code or not.
<snip>
I guess you saw this, but it still didn't seem clear enough?
What if this was extended to something like:
By default this option is set to @samp{auto}, in this mode Python will
check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
if it should write out byte-code or not. When @command{set python
ignore-environment on} has been used then Python will ignore
the environment variable and write out the byte-code files.
I've included the patch below that would make this change.
Thanks,
Andrew
---
commit 1557998d9d8e9b0587500980bd8731bb55a1c299
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date: Thu Apr 29 10:45:17 2021 +0100
gdb/doc: improve description of set python dont-write-bytecode
Extend the description of 'set python dont-write-bytecode' to make the
interaction with 'set python ignore-environment' clearer.
gdb/doc/ChangeLog:
* python.texinfo (Python Commands): Extend description of 'set
python dont-write-bytecode'.
diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 20d65742964..26e1446f005 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -136,8 +136,10 @@
(@pxref{Initialization Files}) to have the desired effect.
By default this option is set to @samp{auto}, in this mode Python will
-check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
-if it should write out byte-code or not.
+check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see if
+it should write out byte-code or not. When @command{set python
+ignore-environment on} has been used then Python will ignore the
+environment variable and write out the byte-code files.
This option is equivalent to passing @option{-B} to the real
@command{python} executable.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-29 9:46 ` Andrew Burgess
@ 2021-04-29 10:08 ` Tom de Vries
2021-05-02 10:31 ` Andrew Burgess
2021-04-29 12:17 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Tom de Vries @ 2021-04-29 10:08 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb-patches
On 4/29/21 11:46 AM, Andrew Burgess wrote:
> * Tom de Vries <tdevries@suse.de> [2021-04-29 10:32:05 +0200]:
>
>> I ran into https://sourceware.org/bugzilla/show_bug.cgi?id=27788 due to
>> having PYTHONDONTWRITEBYTECODE set in my environment. My guess at this
>> point is that this is a test-case issue.
>>
>> I played around a bit with the options and did:
>> ...
>> $ echo $PYTHONDONTWRITEBYTECODE
>> 1
>>
>> $ gdb -q -batch \
>> -iex "set python ignore-environment on" \
>> -iex "show python dont-write-bytecode"
>> Python's dont-write-bytecode setting is auto (currently off).
>>
>> $ gdb -q -batch \
>> -iex "set python ignore-environment off" \
>> -iex "show python dont-write-bytecode"
>> Python's dont-write-bytecode setting is auto (currently on).
>> ...
>> which shows that there is an interaction between the two commands.
>> AFAICT, this is not evident from either the NEWS item, or the docs, and
>> I just wonder whether it's a good idea to make this explicit.
>
> Hi Tom,
>
> Thanks for looking at this feature.
>
> The docs for dont-write-bytecode say:
>
> <snip>
>
> By default this option is set to @samp{auto}, in this mode Python will
> check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
> if it should write out byte-code or not.
>
> <snip>
>
> I guess you saw this, but it still didn't seem clear enough?
>
> What if this was extended to something like:
>
> By default this option is set to @samp{auto}, in this mode Python will
> check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
> if it should write out byte-code or not. When @command{set python
> ignore-environment on} has been used then Python will ignore
> the environment variable and write out the byte-code files.
>
> I've included the patch below that would make this change.
>
Hi Andrew,
LGTM, I just wonder if something like this is not more clear, that is,
reformulate in terms of already explained option value off, rather than
verbosely repeating the off behaviour. So, something like this:
...
By default this option is set to @samp{auto}, in this mode Python will
check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
if it should write out byte-code or not. When @command{set python
ignore-environment on} has been used then auto has the same behaviour as
off.
...
But then again, this may be a bad idea, I'm not sure.
Thanks,
- Tom
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-29 10:08 ` Tom de Vries
@ 2021-05-02 10:31 ` Andrew Burgess
2021-05-02 18:15 ` Tom de Vries
0 siblings, 1 reply; 24+ messages in thread
From: Andrew Burgess @ 2021-05-02 10:31 UTC (permalink / raw)
To: gdb-patches
* Tom de Vries <tdevries@suse.de> [2021-04-29 12:08:50 +0200]:
> On 4/29/21 11:46 AM, Andrew Burgess wrote:
> > * Tom de Vries <tdevries@suse.de> [2021-04-29 10:32:05 +0200]:
> >
> >> I ran into https://sourceware.org/bugzilla/show_bug.cgi?id=27788 due to
> >> having PYTHONDONTWRITEBYTECODE set in my environment. My guess at this
> >> point is that this is a test-case issue.
> >>
> >> I played around a bit with the options and did:
> >> ...
> >> $ echo $PYTHONDONTWRITEBYTECODE
> >> 1
> >>
> >> $ gdb -q -batch \
> >> -iex "set python ignore-environment on" \
> >> -iex "show python dont-write-bytecode"
> >> Python's dont-write-bytecode setting is auto (currently off).
> >>
> >> $ gdb -q -batch \
> >> -iex "set python ignore-environment off" \
> >> -iex "show python dont-write-bytecode"
> >> Python's dont-write-bytecode setting is auto (currently on).
> >> ...
> >> which shows that there is an interaction between the two commands.
> >> AFAICT, this is not evident from either the NEWS item, or the docs, and
> >> I just wonder whether it's a good idea to make this explicit.
> >
> > Hi Tom,
> >
> > Thanks for looking at this feature.
> >
> > The docs for dont-write-bytecode say:
> >
> > <snip>
> >
> > By default this option is set to @samp{auto}, in this mode Python will
> > check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
> > if it should write out byte-code or not.
> >
> > <snip>
> >
> > I guess you saw this, but it still didn't seem clear enough?
> >
> > What if this was extended to something like:
> >
> > By default this option is set to @samp{auto}, in this mode Python will
> > check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
> > if it should write out byte-code or not. When @command{set python
> > ignore-environment on} has been used then Python will ignore
> > the environment variable and write out the byte-code files.
> >
> > I've included the patch below that would make this change.
> >
>
> Hi Andrew,
>
> LGTM, I just wonder if something like this is not more clear, that is,
> reformulate in terms of already explained option value off, rather than
> verbosely repeating the off behaviour. So, something like this:
> ...
> By default this option is set to @samp{auto}, in this mode Python will
> check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
> if it should write out byte-code or not. When @command{set python
> ignore-environment on} has been used then auto has the same behaviour as
> off.
> ...
>
> But then again, this may be a bad idea, I'm not sure.
That seems like a good idea to me.
Here's the patch I propose to push then (pending doc review from Eli).
Thanks,
Andrew
--
commit 98508d108b973838a7d02029e6686756605affd8
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date: Thu Apr 29 10:45:17 2021 +0100
gdb/doc: improve description of set python dont-write-bytecode
Extend the description of 'set python dont-write-bytecode' to make the
interaction with 'set python ignore-environment' clearer.
gdb/doc/ChangeLog:
* python.texinfo (Python Commands): Extend description of 'set
python dont-write-bytecode'.
diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 20d65742964..91c9c121117 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -136,8 +136,10 @@
(@pxref{Initialization Files}) to have the desired effect.
By default this option is set to @samp{auto}, in this mode Python will
-check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
-if it should write out byte-code or not.
+check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see if
+it should write out byte-code or not. When @kbd{set python
+ignore-environment on} has been used then @samp{auto} has the same
+behaviour as @samp{off}.
This option is equivalent to passing @option{-B} to the real
@command{python} executable.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-05-02 10:31 ` Andrew Burgess
@ 2021-05-02 18:15 ` Tom de Vries
0 siblings, 0 replies; 24+ messages in thread
From: Tom de Vries @ 2021-05-02 18:15 UTC (permalink / raw)
To: Andrew Burgess, gdb-patches
On 5/2/21 12:31 PM, Andrew Burgess wrote:
> * Tom de Vries <tdevries@suse.de> [2021-04-29 12:08:50 +0200]:
>
>> On 4/29/21 11:46 AM, Andrew Burgess wrote:
>>> * Tom de Vries <tdevries@suse.de> [2021-04-29 10:32:05 +0200]:
>>>
>>>> I ran into https://sourceware.org/bugzilla/show_bug.cgi?id=27788 due to
>>>> having PYTHONDONTWRITEBYTECODE set in my environment. My guess at this
>>>> point is that this is a test-case issue.
>>>>
>>>> I played around a bit with the options and did:
>>>> ...
>>>> $ echo $PYTHONDONTWRITEBYTECODE
>>>> 1
>>>>
>>>> $ gdb -q -batch \
>>>> -iex "set python ignore-environment on" \
>>>> -iex "show python dont-write-bytecode"
>>>> Python's dont-write-bytecode setting is auto (currently off).
>>>>
>>>> $ gdb -q -batch \
>>>> -iex "set python ignore-environment off" \
>>>> -iex "show python dont-write-bytecode"
>>>> Python's dont-write-bytecode setting is auto (currently on).
>>>> ...
>>>> which shows that there is an interaction between the two commands.
>>>> AFAICT, this is not evident from either the NEWS item, or the docs, and
>>>> I just wonder whether it's a good idea to make this explicit.
>>>
>>> Hi Tom,
>>>
>>> Thanks for looking at this feature.
>>>
>>> The docs for dont-write-bytecode say:
>>>
>>> <snip>
>>>
>>> By default this option is set to @samp{auto}, in this mode Python will
>>> check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
>>> if it should write out byte-code or not.
>>>
>>> <snip>
>>>
>>> I guess you saw this, but it still didn't seem clear enough?
>>>
>>> What if this was extended to something like:
>>>
>>> By default this option is set to @samp{auto}, in this mode Python will
>>> check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
>>> if it should write out byte-code or not. When @command{set python
>>> ignore-environment on} has been used then Python will ignore
>>> the environment variable and write out the byte-code files.
>>>
>>> I've included the patch below that would make this change.
>>>
>>
>> Hi Andrew,
>>
>> LGTM, I just wonder if something like this is not more clear, that is,
>> reformulate in terms of already explained option value off, rather than
>> verbosely repeating the off behaviour. So, something like this:
>> ...
>> By default this option is set to @samp{auto}, in this mode Python will
>> check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
>> if it should write out byte-code or not. When @command{set python
>> ignore-environment on} has been used then auto has the same behaviour as
>> off.
>> ...
>>
>> But then again, this may be a bad idea, I'm not sure.
>
> That seems like a good idea to me.
>
> Here's the patch I propose to push then (pending doc review from Eli).
>
LGTM, thanks.
- Tom
> Thanks,
> Andrew
>
> --
>
> commit 98508d108b973838a7d02029e6686756605affd8
> Author: Andrew Burgess <andrew.burgess@embecosm.com>
> Date: Thu Apr 29 10:45:17 2021 +0100
>
> gdb/doc: improve description of set python dont-write-bytecode
>
> Extend the description of 'set python dont-write-bytecode' to make the
> interaction with 'set python ignore-environment' clearer.
>
> gdb/doc/ChangeLog:
>
> * python.texinfo (Python Commands): Extend description of 'set
> python dont-write-bytecode'.
>
> diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
> index 20d65742964..91c9c121117 100644
> --- a/gdb/doc/python.texi
> +++ b/gdb/doc/python.texi
> @@ -136,8 +136,10 @@
> (@pxref{Initialization Files}) to have the desired effect.
>
> By default this option is set to @samp{auto}, in this mode Python will
> -check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
> -if it should write out byte-code or not.
> +check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see if
> +it should write out byte-code or not. When @kbd{set python
> +ignore-environment on} has been used then @samp{auto} has the same
> +behaviour as @samp{off}.
>
> This option is equivalent to passing @option{-B} to the real
> @command{python} executable.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-29 9:46 ` Andrew Burgess
2021-04-29 10:08 ` Tom de Vries
@ 2021-04-29 12:17 ` Eli Zaretskii
2021-04-29 12:32 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2021-04-29 12:17 UTC (permalink / raw)
To: Andrew Burgess; +Cc: tdevries, gdb-patches
> Date: Thu, 29 Apr 2021 10:46:42 +0100
> From: Andrew Burgess <andrew.burgess@embecosm.com>
> Cc: gdb-patches@sourceware.org
>
> --- a/gdb/doc/python.texi
> +++ b/gdb/doc/python.texi
> @@ -136,8 +136,10 @@
> (@pxref{Initialization Files}) to have the desired effect.
>
> By default this option is set to @samp{auto}, in this mode Python will
> -check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see
> -if it should write out byte-code or not.
> +check the environment variable @env{PYTHONDONTWRITEBYTECODE} to see if
> +it should write out byte-code or not. When @command{set python
> +ignore-environment on} has been used then Python will ignore the
> +environment variable and write out the byte-code files.
@command is the markup for programs, not for command lines. Command
lines should be in @kbd, as that is what the user types on the
keyboard.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/7] gdb: startup commands to control Python extension language
2021-04-29 12:17 ` Eli Zaretskii
@ 2021-04-29 12:32 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2021-04-29 12:32 UTC (permalink / raw)
To: andrew.burgess; +Cc: gdb-patches
> Date: Thu, 29 Apr 2021 15:17:00 +0300
> From: Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>
> Cc: gdb-patches@sourceware.org
>
> @command is the markup for programs, not for command lines.
To clarify, by "programs" I mean names of program executable files.
Like @command{gdb}, @command{gcc}, @command{make}, etc. The Texinfo
manual says:
Use the '@command' command to indicate command names, such as 'ls' or
'cc'.
^ permalink raw reply [flat|nested] 24+ messages in thread