Re: Breakpoint commands compiler

[Doug Evans <xdje42@gmail.com>]

On Fri, Oct 17, 2014 at 8:42 AM, Daniel Gutson
<daniel.gutson@tallertechnologies.com> wrote:
> Hi,
>
>     gdb is sometimes used for changing the runtime behavior of a program.
> That is, suppose there is a program that has a bug,
> it is spotted with gdb, then I create a set of non-stopping breakpoints that
> "fix" the runtime behavior by altering memory and registers.
> It does work, but it's slow.
>
> I was thinking to start a project to add a "breakpoint commands compiler"
> to gdb, which basically generates C code from the breakpoint commands
> (one function per breakpoint),
> which in turns calls a C API (similar to the python api), invokes the compiler
> (user-specified), loads it as a shared object, and finally replaces the commands
> of the breakpoints by calls to the compiled breakpoint-functions.
>
> Any comment/suggestion? Would this be accepted within gdb?

Hi.

For reference sake a patch has been submitted by Red Hat to add a
"compile" command.
[The patch is still being reviewed, it hasn't been committed yet.]
It doesn't compile gdb commands, but allows one to add compiled code
to the inferior in the debugging session.

The problem with attaching this code to breakpoints is that
breakpoints are handled exterior to the program (the inferior gets,
e.g., a SIGTRAP and gdb processes the signal - the inferior never sees
it).  If you wanted to add compiled code that ran when the breakpoint
was "hit" you'd need to solve this problem.

There are "agent expressions" which support a limited number of
gdb-like things and are compiled as bytecode.
They can even be run without communication with gdb when used with gdbserver.
There is even a jitter to support limited things like fast conditional
breakpoints.
Part of the gdb/gdbserver unification project is to add support for
agent expressions to gdb.
https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
But until then agent expressions are only supported by gdbserver.

Hope that helps.
I think a feature to compile gdb commands to C would not be accepted,
at least not in that form.
But limited extensions of the above features (and certainly assistence
with LocalRemoteFeatureParity) would be welcome.