Re: Spotting inferior function calls from Python

[Phil Muldoon <pmuldoon at redhat dot com>]

On 05/04/13 12:48, Nick Bull wrote:
> Hi,
> 
> I would like my Python code to be notified when gdb causes a function to be
> run on the inferior outside of the normal program flow.  For example, this
> could be used to warn the user that any side-effects might change future
> program execution.
> 
> I can't simply hook the 'call' command because there are many other
> commands which could in principle invoke inferior functions, and too many
> false positives would be inconvenient.
> 
> It looks as though all such function calls happen via
> call_function_by_hand. So the simplest approach would be for me to create a
> new observer type which is notified in call_function_by_hand, and a
> corresponding Python event type. Does that sound sensible?

I think all inferior function calls go through call_function_by_hand.
However inferior function calls can happen in lots of places in GDB,
not just via the call CLI command.  Another question to think about is
when do you trigger the event? Before the dummy frame is constructed?
After the inferior function call has executed? After the dummy frame
has been constructed but before the function call has been executed?
These are important as they will affect the call stack.  If you
created the event after the dummy frame has been created, but before
the inferior function call has been executed, there will be a dummy
frame in your call stack.  Will that affect the Python user, or, in
your example, your use case?

Some examples of inferior function calls are:

- When an expression is evaluated.  If an expression contains a call
into the inferior, then the inferior function call is completed when
the expression is evaluated.  E.g, (gdb) p foo().  The "foo()" bit is
evaluated by the print command which leads to the inferior function
call.  This applies to things like conditional breakpoints, and any
command that takes and evaluates an expression.

- The direct "call" command.

- via Python API gdb.parse_and_eval().  This hooks into the same
evaluation engine as the first point.

- Via the gdb.Value() callable interface (when a gdb.Value represents
a pointer to a function).

There are probably more.  But the point is you cannot usefully
delineate or categorize where the call originates from for usage
purposes.  You have to catch them all.  However, from the point of view
of Python I don't think that matters; provide the observer ->
observable and let the (user provided) Python code either act or
ignore it.

> And is such a patch likely to be accepted for inclusion, assuming all
> formatting and copyright assignment requirements are met?

Nobody can say.  And I am not a maintainer, so I don't speak for that
group.  But I think I can confidently say that if you submit a patch
it will be constructively reviewed in a positive and impartial
manner.  If there are problems, or the maintainers disagree about
implementation, then you will be expected to argue your point
convincingly or make the changes.  I have submitted many patches, and
not once have I ever felt unfairly dealt with.  It has all been
positive.

Cheers,

Phil