Re: About adding new script language

Doug Evans
2013-05-01T04:31:57Z

On Tue, Apr 30, 2013 at 8:49 PM, Nala Ginrut <mulei@gnu.org> wrote:
> hi Doug! Thanks for reply!
>
> On Tue, 2013-04-30 at 17:51 -0700, Doug Evans wrote:
>> There aren't any interfaces, they need to be added.
>> One of the hardest parts of adding Guile support to GDB (as an
>> extension language)
>> will be providing reasonable interfaces.
>>
>
> Could you give me some hints where is the preferable place to cut in?

Not at this time.
If it were me, I'd study the gdb/python directory,
and all the places in gdb/*.c that call into gdb/python/*.c.
[There may be other places in cli/*.c and mi/*.c, I don't know off hand
and it's trivial to check.]

> Here're my questions:
> 1. Find a way to get the input string and pass it to guile for eval when
> 'Guile mode' enabled. I know python module has some functions to handle
> this, but I don't know how the things from GDB passed in. Maybe some
> hooks in GDB REPL?

For a first pass, I would not invent anything new.
[If you want to try to invent sometthing, I"m not saying don't try,
but I think you'll get better traction, and get up to speed quicker,
by not trying to invent anything, and start by just providing in gdb+Guile
what is already provided in gdb+Python.]

GDB provides the "python-interactive" command
to invoke the Python REPL. Thus if you want a Guile REPL from
GDB, write a guile-interactive (scheme-interactive?) command
that starts a Guile REPL.
Also, GDB also provides Python access to gdb's stdout,etc (see
gdb/python/python.c).
And there is gdb/python/py-gdb-readline.c to provide Python
access to GDB's readline.

> 2. When in 'Guile mode', there should be a way to get the context info
> of gdb. I know python could do it with gdb module, like 'gdb.a' to get
> the variable named 'a'. My question is how to interact with GDB context?
> Any docs for that?

There is the gdb module in Python, but "gdb.a" is not used to get the
variable named "a". One way would be gdb.parse_and_eval("a").

There are no such internal docs that I'm aware of.
If it were me, I'd just look at the code anyway.

OTOH, there are lots of docs for the Python API from the user's perspective.
E.g.,
bash$ info -f gdb -n Python

> 3. According to our previous discussion, there's no need to write a
> general interfaces for extension language (maybe not?). So I think the
> easier way is to find out what's in GDB is most useful thing, and write
> the wrapper for Guile. Any suggestion?

Depends I think.
I think(!) we definitely do not want the following littered throughout gdb
(for example):

#ifdef HAVE_PYTHON
if (using_python)
python_api_func_1 ();
#endif
#ifdef HAVE_GUILE
if (using_guile)
guile_api_func_1 ();
#endif

Not because I'm thinking we might someday want to add another language,
but simply because even with only two languages it's too clumsy.

> 4. If we do need to add the clean interfaces, what part of code should I
> take a look?

I'm not sure in the general case.
I can think of a way to go that would work for me,
but no one has really looked at supporting multiple scripting languages.
The canonical solution would be a struct with some state and a set of
function pointers defining the API, with the Python implementation
in gdb/python/*.c and the Guile implementation in gdb/guile/*.c.
[More would be needed on top of that, but that's a start.]