This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About adding new script language


On Tue, Apr 30, 2013 at 12:49 AM, Nala Ginrut <mulei@gnu.org> wrote:
> 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.

Hi.
Your interpretation of language_defn is correct.
The Python extension support in GDB uses language_defn only to implement
various API calls.  E.g. when printing a value one might want to know the
(programming) language in which to print it.

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

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.

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

It's not unrealistic.  It's easier to add a second one now that the
first is there.
However, as I said, adding clean interfaces will be important.
We want the end result to be maintainable, and supporting multiple
extension languages is going to complicate things.
[It will be easier in the sense that we're not interested in supporting
and arbitrary number of extension languages.]


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]