[PATCH 00/13] script language API for GDB

[PATCH 00/13] script language API for GDB

[Doug Evans]

Hi.

My patch set to add a scripting API to GDB is ready for submission.
It sets things up so that adding Guile scripting is straightforward.
I've cc'd guile-users to apprise them of my progress.
I'll spare them the actual set of patches here,
though I plan to cc them when submitting the Guile port,
their input will be helpful.
The actual Guile port is ready ... just have some more docs to write. :-)

This patch set also has a nice effect of formalizing the interface from
GDB to Python (one aspect of which is that it removes the need for
a lot if #ifdef HAVE_PYTHON's, and it removes all the little stubs that
had to be provided when GDB was compiled --without-python).

The main patches are 02 and 03.
02 adds scripting.c, scripting.h, and scripting-priv.h.
03 updates python.c, python.h, and python-internal.h.
The rest are pretty-straightforward.

A lot of the change is mechanical:
- I want to have each ops "method" named ${lang}_${method_name}.
- Plus I want to have each API entry point have something in its
  name that says "I am a scripting API entry point".
  My first attempt used slang_ but that was thought to have
  to much potential confusion with the slang scripting language.
  Instead I've taken a minimalist approach and added "script"
  to the function name.
  E.g., apply_val_pretty_printer -> apply_val_script_pretty_printer
- Then I needed to move the interface enums defined in python.h
  out and make the values have non-python-specific names.

I'm going to wait until after 7.7 has been branched
before checking anything in of course.

Re: [PATCH 00/13] script language API for GDB

[Doug Evans]

Ok, let's try this again.

On Thu, Dec 5, 2013 at 9:05 AM, Doug Evans <xdje42@gmail.com> wrote:
> Hi.
>
> My patch set to add a scripting API to GDB is ready for submission.
> It sets things up so that adding Guile scripting is straightforward.
> I've cc'd guile-users to apprise them of my progress.
> I'll spare them the actual set of patches here,
> though I plan to cc them when submitting the Guile port,
> their input will be helpful.
> The actual Guile port is ready ... just have some more docs to write. :-)
>
> This patch set also has a nice effect of formalizing the interface from
> GDB to Python (one aspect of which is that it removes the need for
> a lot if #ifdef HAVE_PYTHON's, and it removes all the little stubs that
> had to be provided when GDB was compiled --without-python).
>
> The main patches are 02 and 03.
> 02 adds scripting.c, scripting.h, and scripting-priv.h.
> 03 updates python.c, python.h, and python-internal.h.
> The rest are pretty-straightforward.
>
> A lot of the change is mechanical:
> - I want to have each ops "method" named ${lang}_${method_name}.
> - Plus I want to have each API entry point have something in its
>   name that says "I am a scripting API entry point".
>   My first attempt used slang_ but that was thought to have
>   to much potential confusion with the slang scripting language.
>   Instead I've taken a minimalist approach and added "script"
>   to the function name.
>   E.g., apply_val_pretty_printer -> apply_val_script_pretty_printer
> - Then I needed to move the interface enums defined in python.h
>   out and make the values have non-python-specific names.
>
> I'm going to wait until after 7.7 has been branched
> before checking anything in of course.
>

Re: [PATCH 00/13] script language API for GDB

[Phil Muldoon]

On 06/12/13 05:51, Doug Evans wrote:
> Ok, let's try this again.
> 
> On Thu, Dec 5, 2013 at 9:05 AM, Doug Evans <xdje42@gmail.com> wrote:
>> Hi.
>>
>> My patch set to add a scripting API to GDB is ready for submission.
>> It sets things up so that adding Guile scripting is straightforward.
>> I've cc'd guile-users to apprise them of my progress.
>> I'll spare them the actual set of patches here,
>> though I plan to cc them when submitting the Guile port,
>> their input will be helpful.
>> The actual Guile port is ready ... just have some more docs to write. :-)

Thanks I reviewed the series.  Most comments are inline.  I will do a summary here.

More documentation.  The API implementer really needs to know about
what they have to really implement over what is optional.  An addition
to the internals manual would be super. At the very least far more
comments in the structures.

Scripting language priority needs to be looked at in certain
situations.  I documented my thoughts in-line. But as I presume each
scripting language keeps its own meta-data, (IE printer lists), we
will have to refactor the "info
frame-filter/type-printer/pretty-printer" commands to work with all of
them.

Internal naming nits.

A few comments on some breakpoint struct changes.

Cheers,

Phil

Re: [PATCH 00/13] script language API for GDB

[Doug Evans]

Phil Muldoon <pmuldoon@redhat.com> writes:
> On 06/12/13 05:51, Doug Evans wrote:
>> Ok, let's try this again.
>> 
>> On Thu, Dec 5, 2013 at 9:05 AM, Doug Evans <xdje42@gmail.com> wrote:
>>> Hi.
>>>
>>> My patch set to add a scripting API to GDB is ready for submission.
>>> It sets things up so that adding Guile scripting is straightforward.
>>> I've cc'd guile-users to apprise them of my progress.
>>> I'll spare them the actual set of patches here,
>>> though I plan to cc them when submitting the Guile port,
>>> their input will be helpful.
>>> The actual Guile port is ready ... just have some more docs to write. :-)
>
> Thanks I reviewed the series.  Most comments are inline.  I will do a summary here.
>
> More documentation.  The API implementer really needs to know about
> what they have to really implement over what is optional.  An addition
> to the internals manual would be super. At the very least far more
> comments in the structures.

Righto.
My plan is to augment the internals manual in time.

> Scripting language priority needs to be looked at in certain
> situations.

Indeed.  My intention is that in cases where it matters
the first one wins, and python will stay first in the list.

> I documented my thoughts in-line. But as I presume each
> scripting language keeps its own meta-data, (IE printer lists), we
> will have to refactor the "info
> frame-filter/type-printer/pretty-printer" commands to work with all of
> them.

One thought I have for this is "info guile pretty-printer", etc.
That simplifies a lot of things.
From a u/i perspective it has both plusses and minuses, but I like it overall.

> Internal naming nits.
>
> A few comments on some breakpoint struct changes.
>
> Cheers,
>
> Phil

Re: [PATCH 00/13] script language API for GDB

[Tom Tromey]

>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:

Doug> One thought I have for this is "info guile pretty-printer", etc.
Doug> That simplifies a lot of things.  From a u/i perspective it has
Doug> both plusses and minuses, but I like it overall.

The problem with this approach is that it assumes that the user both
knows and cares in which extension language a given feature is
implemented.  However, I don't believe either of those is true in the
most common situations.  My experience with the libstdc++ printers is
that most people want them to "just work" and that any amount of
required under-the-hood knowledge is too much of a burden.

Tom

Re: [PATCH 00/13] script language API for GDB

[Doug Evans]

[+ guile-user
For background: https://sourceware.org/ml/gdb-patches/2013-12/msg00243.html ]

On Fri, Dec 20, 2013 at 8:26 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:
>
> Doug> One thought I have for this is "info guile pretty-printer", etc.
> Doug> That simplifies a lot of things.  From a u/i perspective it has
> Doug> both plusses and minuses, but I like it overall.
>
> The problem with this approach is that it assumes that the user both
> knows and cares in which extension language a given feature is
> implemented.  However, I don't believe either of those is true in the
> most common situations.  My experience with the libstdc++ printers is
> that most people want them to "just work" and that any amount of
> required under-the-hood knowledge is too much of a burden.

OTOH, there are situations where a user can care.

For those that don't care, "info pretty-printer" can still print all of them.
"info pretty-printer" et.al. would need some work, sure, and one way
to go would be to use
"info <ext-lang> pretty-printer".

Re: [PATCH 00/13] script language API for GDB

[Tom Tromey]

>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:

Doug> For those that don't care, "info pretty-printer" can still print
Doug> all of them.  "info pretty-printer" et.al. would need some work,
Doug> sure, and one way to go would be to use "info <ext-lang>
Doug> pretty-printer".

I don't understand what this means.

Tom

Re: [PATCH 00/13] script language API for GDB

[Doug Evans]

On Mon, Dec 23, 2013 at 1:54 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:
>
> Doug> For those that don't care, "info pretty-printer" can still print
> Doug> all of them.  "info pretty-printer" et.al. would need some work,
> Doug> sure, and one way to go would be to use "info <ext-lang>
> Doug> pretty-printer".
>
> I don't understand what this means.

The "info pretty-printer" command would invoke "info <ext-lang> pretty-printer".