This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Turn check macros into functions. (issue6188088)


On 5/21/12, Mike Stump <mikestump@comcast.net> wrote:
> 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?!

For variables that are not optimized out of memory, I think this
can work.  But if you need to go for registers, or undo a variable
elimination, the effort gets harder.

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

Agreed.

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

Yes, you essentially need to come close to sending the compiler's
symbol tables through the debug information.  I don't know of any
compiler/debugger pair that is close to that capability.  That said,
I don't know all such pairs either.

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

Agreed.

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

I'm not saying that the task is impossible, only that there is a
lot of work to do before we get there.

-- 
Lawrence Crowl


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]