About adding new script language

About adding new script language

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hi GDB folks!
I'm new comer here, and I'm trying to make guile the extension language.
Anyway, folks could use python as well, before guile has reliable python
front-end.
I've read the python part, here're some ideas, correct me if I'm wrong
please. ;-)

1. Is it necessary to use language_defn to define the extension
language?
My understanding is language_defn defines a new language support for
debugging the defined language, not to define a new extension language
for other debugging purpose. Or not?
For example, go-lang.c is the support for debugging go, not add go as
the debug script language, just like python. But it confused me that
python has used language_defn.

2. There should be interfaces to add the script language, but I didn't
find it, anyone point me out? I don't think I have to write new
lexer/parser for that, just need a way to get the expr and call guile's
read function. Thanks!

3. My aim is not only add guile as an extension in gdb's REPL, but a
more powerful language for the automatic debugging. For that purpose,
the hard/heavy work is not to add guile into gdb, but a framework
project implemented by guile based on the support of guile-gdb. 
Is this idea too unrealistic?

Happy hacking!
Thanks!



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: About adding new script language

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

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?
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?

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?

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? 

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

Thanks!


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: About adding new script language

[Doug Evans]

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.]