Re: Breakpoint commands compiler

[David Taylor <dtaylor@usendtaylorx2l.lss.emc.com>]

 1961+-07/28 To:"gdb@sourcewar  possible gdb agent expression extension<<We're 
 1962  07/28 To:"gdb@sourcewar  possible 'info macro' extension<<To expand a ma

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.

Agreed.  Additionally speeding up the debug -- edit -- build -- download
& boot cycle is a concern of ours.

For us, while it only takes about 5 minutes to do a full build from
scratch, the build -- download & boot part takes about 30 minutes.  Some
threads have timing constraints -- if the thread is left stopped waiting
on the user to continue it, it will bring down the system.  Other
threads can wait an hour or more and it's no big deal.

Depending on the problem being debugged, you might need additional time
to get the system into the 'failing' state.  So, the ability to 'patch'
via debugger commands was desirable.

Also, for unit testing it is nice to be able to artificially alter
variables.

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

Another option would be, if the target supports it, to download the
breakpoint commands to the target and have the target execute them.

In the remote protocol the Z0 command takes an optional cond_list and an
optional cmd_list.

Back on July 28th I posted a message, subject 'possible gdb agent
expression extension' that partially addresses this.  Judging from the
response, or should I say lack of response, no one seemed to care.

The proposal addresses the setting variables part of the problem.  We
went ahead with it and it is about half done.  The pieces remaining are
primarily the gdbserver and testsuite changes.  I keep getting pulled
onto other tasks, but I'm *hoping* to finish it before the end of the
year.

It's only useful if you have a remote target and the target supports
agent bytecode expressions.

There are many things missing from agent bytecode expressions to make
them as useful as I'd like.  But, it's a start.  The biggest missing one
is the lack of 'continue'.  But, for 'continue', there is a workaround
-- put the expressions into the condition and use the comma operator:

    real-condition && ((variable1 = value1), (variable2 = value2), 0)

[My other proposal on that same day -- possible 'info macro' extension
-- elicited no responses.]