Breakpoint commands compiler

[Daniel Gutson]

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?

Thanks,

Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina


Phone: [phone]

Skype: dgutson

[Daniel Gutson]

On Fri, Oct 17, 2014 at 12:42 PM, Daniel Gutson

Post by Daniel Gutson
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

(Note: I just saw the C API discussion in this list. Funny).

Post by Daniel Gutson
(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?
Thanks,
Daniel.
--
Daniel F. Gutson
Chief Engineering Officer, SPD
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: [phone]
Skype: dgutson

--
Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina


Phone: [phone]

Skype: dgutson

[Doug Evans]

On Fri, Oct 17, 2014 at 8:42 AM, Daniel Gutson

Post by Daniel Gutson
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.

[Phil Muldoon]

Post by Doug Evans
On Fri, Oct 17, 2014 at 8:42 AM, Daniel Gutson

Post by Daniel Gutson
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.

Just as an an add-on, we've begun detailing the internals of the
compile command here:

https://sourceware.org/gdb/wiki/GCCCompileAndExecute

That page is draft and is not complete yet. It should be complete
soon.

A minor status update. I will be checking the GCC patches in next
week (we have permission there). And then we will be
pursuing/re-pinging the GDB patches right after.

Cheers

Phil

[Jan Kratochvil]

Post by Doug Evans
For reference sake a patch has been submitted by Red Hat to add a
"compile" command.

https://sourceware.org/gdb/wiki/GCCCompileAndExecute

as written primarily by Phil recently mentions
Currently the project does not “patch in” the newly compiled bytes at
the program counter. That might be a viable solution in the future,
perhaps as we explore other avenues for this project (like “fast”
breakpoints).

There are such plans intended as fast breakpoint conditions evaluation similar
to current agent expressions but more general.

What Daniel Gutson mentions is IMO "fix-and-continue", this was implemented by
Apple in GDB-6.3 - Googled now its announcement:
https://www.sourceware.org/ml/gdb/2003-06/msg00500.html
It is one of the possible future goals of the "compile" project above although
currently it is considered as pretty far goal.


Jan

[David Taylor]

Post by Daniel Gutson
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.

Post by Daniel Gutson
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.]