RE: [PATCH] python: accept address and explicit locations in gdb.decode_line

["Metzger, Markus T" <markus.t.metzger@intel.com>]

Hi Keith,

Thanks for your quick review.


> > It's not clear to me whether I should use python_language or
> current_language,
> > though.  Is there some comment that explains it?
> 
> Although string_to_event_location_basic does not use the language
> parameter, I kept it for parallelism with string_to_event_location. What
> can I say? I really dislike using globals!
> 
> The correct language to use is the language in which the linespec is to
> be evaluated. Most typically, that is current_language.

I found this comment in gdb/python/python.c:

/* Architecture and language to be used in callbacks from
   the Python interpreter.  */
struct gdbarch *python_gdbarch;
const struct language_defn *python_language;


The function this patch is modifying is:

/* A Python function which is a wrapper for decode_line_1.  */

static PyObject *
gdbpy_decode_line (PyObject *self, PyObject *args)


I'd say this qualifies as a callback from the Python interpreter.


I don't see how this is intended to work when those callbacks call
GDB functions.  As long as language and gdbarch are passed as
arguments, we're fine.  But making sure to not add an implicit use
of current_language or target_gdbarch () that ends up being used
by the Python layer sounds a bit tricky to me.

Maybe I got the whole idea behind it wrong.

Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928