Turn check macros into functions. (issue6188088)

[Mike Stump]

On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
> On 5/17/12, Mike Stump <mikestump@comcast.net> wrote:
>> On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
>>>> Reusing the compiler for this seems like the only way to go.
>>>> But, we did look at using g++ to parse C++ expressions from gdb,
>>>> and it was too slow :-(.  We're going to look again, at least to
>>>> generate some bug reports if we can.
>>> 
>>> It's a tough problem, particularly as C/C++ and their compilers
>>> were not designed for a read-eval-print-loop environment.
>> 
>> This of course is trivial to do,
> 
> I do not think that word means what you think it means.  :-)

Excellent reference...  Yeah, well, just a little more work to do:

$ ./eval
extern "C" int printf(const char *...); int &k2 = *(int*)4294971592; void eval()\
 { printf("k is %d\n", k2); }
about to run
k is 42
done running, took 32540 usecs


Notice, this sucked a int k2 = 42; that was a variable inside the context in which I wanted a k2.  The nature of the variable is irrelevant, could be a stack variable, could be a global, a static top-level, all I need to know, is where it is (the address) and the type and I generate a binding stub for it into the context, and presto, complete access to most all variables.  This does make use of C++ to manage the variables in a slightly nicer way.  One either has to inject all variables and functions into the context into which the program fragment is compiled, or notice which variables and function are or might be used and inject just those.

I've seen ptype foo print the types of variables, so, it isn't far off, and certainly gdb knows about the symbol table and can figure out the addresses of those variables, right?!

Now, certainly one can find additional issues, and yes, there is a bit of work to get 100% reliability that we'd like from the scheme.  For example, packed structures would need work, as ptype isn't going to get that right from that start.  I think the functionality one would get would be good enough to start with, and in time, better support for things ptype doesn't get right would fix a certain class of problems.

So, what another 1000 lines to generate the context for the fragment... I guess finding references could be annoying, and the time required to generate and compile the entire context could be annoying...

Doing C++ would be harder, though, not quite for the reason you gave.

> I like the example, but it sidesteps the main problem, which is
> putting the expression in the context from which it was called.
> For instance if I stop in the middle of a function and type
> 
>  print foo->bar( a + b )
> 
> I need to find the find the variable names, lookup their types,

ptype a does the lookup for a, and finds the type, so that isn't hard, same with b and foo.  Harder would be to synthesize the context for the fragment to live in.  To do this and work with templates, you'd need the entire template bodies to be in the debug information and to output them when generating the context that might use them.

class A {
  foo() { }
}

when stopped in foo, one needs to generate:

class A {
  foo();
  __eval() { fragment }
}

and then call __eval(lookup("this"))...  The compiler does the overload resolution, the template instantiation and so on.  To ensure the compiler does name loookup right, one just needs to generate the context for that fragment carefully.

> do overload resolution, possibly do template instantiation, etc,
> all as if the compiler was in the scope defined for the line that
> the debugger is stopped at.  That's the hard part.