Debugging C++ Function Calls

[Lawrence Crowl <crowl at googlers dot com>]

On 3/25/13, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Lawrence" == Lawrence Crowl <crowl@googlers.com> writes:
>
> Lawrence> My model is that I should be able to cut and paste an expression
> Lawrence> from the source to the debugger and have it work.  I concede that
> Lawrence> C++ function overload resolution is a hard problem.  However, gdb
> Lawrence> has a slightly easier task in that it won't be doing instantiation
> Lawrence> (as that expression has already instantiated everything it needs)
> Lawrence> and so it need only pick among what exists.
>
> Yeah, what isn't clear to me is that even this can be done in a
> behavior-preserving way, at least short of having full source available
> and the entire compiler in the debugger.
>
> I'd be very pleased to be wrong, but my current understanding is that
> one can play arbitrary games with SFINAE to come up with code that
> defeats any less complete solution.

Hm.  I haven't thought about this deeply, but I think SFINAE may
not be less of an issue because it serves to remove candidates
from potential instantiation, and gdb won't be instantiating.
The critical distinction is that I'm not trying to call arbitrary
expressions (which would have a SFINAE problem) but call expressions
that already appear in the source.

I agree that the best long-term solution is an integrated compiler,
interpreter, and debugger.  That's not likely to happen soon.  :-)

>
> Sergio is going to look at this area again.  So if you know differently,
> it would be great to have your input.
>
> I can dig up the current ("pending" -- but really unreviewed for a few
> years for the above reasons) gdb patch if you are interested.  I believe
> it worked by applying overload-resolution-like rules to templates
> (though it has been a while).

I don't know anything about gdb internals, so it may not be helpful
for me to look at it.

-- 
Lawrence Crowl