Re: [PATCH 0/1] Integrate GNU poke in GDB

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

> Jose> It allows the GDB user to execute Poke code from within the
> Jose> debugger with access to the target memory, types and values.
>
> Jose> - Eventually we will probably want to ship some prewritten Poke
> Jose>   code in a pickle gdb.pk.  Would $pkddatadir/poke/ be a good
> Jose>   location for Poke code distributed with GDB?
>
> Like what kind of thing are you thinking?

Any Poke code that is specific to GDB in any way.  For example, this
code is part of the initialization and opens the IO space for the
current target provided by GDB:

  open ("<gdb>");

In fact in an initial version I had put that in a gdb.pk file that was
loaded in start_poke.  But since I didn't need to add anything else
there, I decided to just do it from C instead:

  if (pk_compile_statement (poke_compiler, "open (\"<gdb>\");", NULL, &val)
      != PK_OK)
    error (_("Could not open <gdb>"));

> Jose> - There are three commands:
>
> Jose>   poke STR
> Jose>   poke-add-type EXPR
> Jose>   poke-add-types REGEXP
> Jose>   poke-dump-types
>
> Jose>   All three commands make sure to start the poke incremental
> Jose>   compiler if it isn't running already.
>
> It's maybe more gdb-ish to make one command and use subcommands.

What would be the gdb-ish way:

a) poke STR
   poke add-type EXPR
   poke add-types REGEXP
   poke dump-types

or

b) poke STR
   poke add type EXPR
   poke add types REGEXP
   poke dump types

Because a) will be problematic: `add-types' can be a valid Poke
expression if both `add' and `types' are defined as variables.

Doing b) would be ok I think.

> I wonder if you considered implementing this by writing some Python to
> glue Poke into gdb.  This would have some advantages:
>
> * It wouldn't be a configure-time decision by whoever built gdb -- if
>   you have Poke, it could "just work".  (Of course this assumes gdb is
>   built with Python, but that's the norm for distros.)
>
> * How Poke is glued in and how the commands work would be controlled by
>   ordinary Poke patches, rather than having to go through GDB.  This
>   would let you evolve the GDB integration along with the library.

That is a very clever idea that no, I had not considered.

But I am not really looking forward to write Python bindings for libpoke
(or Python for anything for that matter) and even if I could recruit
someone to do that work, the stuff would need to be maintained ... poke
depending on Python, supporting future Python versions and what not,
argh no no no no :)

Also somehow I would not feel comfortable getting into such troubles and
going C++->Python->C->Poke for something that can be simply achieved as
C++->Poke in about 700 lines of C++.

So unless there is a strong feeling about this on the GDB side, I would
much prefer to integrate via libpoke directly.

PS: If GDB supported writing plugins in C or C++ like bash does, I
    wouldn't blink twice before adopting your suggestion!