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

[+ 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".