Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Using the CDT parser for debug expressions?

You can create the ast through public API:
 
   CodeReader reader = new CodeReader(("void dummy_func() { " + _expression_ + " ; }").toCharArray());
   IScannerInfo scannerInfo = new ScannerInfo(); // creates an empty scanner info
   ICodeReaderFactory factory = new NullCodeReaderFactory(); // don't need to follow include directives
   IIndex index = ...;
   ILogService log= ...;
   ILanguage lang= GPPLanguage.getDefault(); // GCCLanguage.getDefault();
   IASTTranslationUnit tu= lang.getTranslationUnit(reader, scannerInfo, factory, index, log);
 
Markus.


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Kucera
Sent: Wednesday, June 10, 2009 5:29 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Using the CDT parser for debug expressions?
Importance: Low

Hi Ken,

I'm not entirely sure what you need to do, and I have zero experience with how debuggers work, but maybe I can still help.

Now, If you just need to parse a snippet of C code then that's easy enough to do. You don't need an entire TranslationUnit, you can use the parser/scanner APIs directly. You can't call the parser on an _expression_ directly, like Ed said you will need to wrap the _expression_ in a dummy function body.

CodeReader reader = new CodeReader(("void dummy_func() { " + _expression_ + " ; }").toCharArray());
IScannerInfo scannerInfo = new ScannerInfo(); // creates an empty scanner info
ICodeReaderFactory factory = new NullCodeReaderFactory(); // don't need to follow include directives
IScanner scanner = new CPreprocessor(reader, scannerInfo, ParserLanguage.C, new NullLogService(), factory);
ISourceCodePaser parser = new GNUCSourceParser(scanner, ParserMode.COMPLETE_PARSE, new NullLogService(), GCCParserExtensionConfiguration.getInstance(), null);
IASTTranslationUnit ast = parser.parse();

Then extract the AST for the _expression_ from the function body.

Do you need to be able to resolve bindings for identifiers in the expresssion using the index? If so then the _expression_ will need to be parsed within the context of the TranslationUnit that is being debugged, and the code above won't be enough. Otherwise if you can get the values of variables from the call stack then you probably don't need to resolve the bindings. Do you need to be able to evaluate complex or side-effecting expressions like function or method calls or expressions involving templates?

Parsing is simple enough, I think the real challenge here is determining how to evaluate the _expression_. Unlike JDT we don't have our own built-in compiler or a virtual machine that lets you swap in code. You could write your own symbolic _expression_ interpreter and evaluate the AST directly, but that might be difficult to do and might not be fully accurate.

We do have an ExpressionEvaluator class for for the preprocessor for evaluating #if directives. However it only supports simple expressions and is coupled very tightly with our preprocessor. You might want to take a quick look at that class to see if you want to do something similar.

Mike Kucera
Software Developer
IBM Eclipse CDT Team
mkucera@xxxxxxxxxx

Inactive hide details for ---06/10/2009 10:01:43 AM---Hi Ken,---06/10/2009 10:01:43 AM---Hi Ken,


From:

<Ed.Swartz@xxxxxxxxx>

To:

<cdt-dev@xxxxxxxxxxx>

Date:

06/10/2009 10:01 AM

Subject:

RE: [cdt-dev] Using the CDT parser for debug expressions?




Hi Ken,

I'm of course not an expert but I've been down this path before. There's some more API for this since the last time I looked, but in 5.0.x I thought this would be a way to do this:

IStorage storage = /* some custom in-memory implementation */;
IASTTranslationUnit tu = CDOM.getTranslationUnit(storage, project);

But I see that 'storage' is only used to fetch a path, and then the core assumes everything's in a file. I assume the debugger won't want to write a lot of files to populate the Variables view...

Another approach requires touching non-API code but you should at least be able to control where the parsed content comes from:

ILanguage language = GCCLanguage.DEFAULT_INSTANCE;
IIndex index = CCorePlugin.getIndexManager.getIndex(project, 0 /* ?? */);

IScanner scanner = new CPreprocessor/**non API**/(.. lots of stuff you have to implement or instantiate...);
ISourceCodeParser parser = language.createParser(scanner, ParserMode.QUICK_PARSE /* ?? */, new DefaultLogService(), index);

IASTTranslationUnit tu = parser.parse();

... then see what 'tu' has to offer. N.B. you'll probably need to wrap the _expression_ in a dummy function body, like "void debugger_func() { /* _expression_ */ } ".

You would need to manually visit this tree to evaluate the _expression_ or find something that does it for you.

An important question, though, is how the TU will respond to all the identifiers, struct/class dereferences, etc. it will encounter along the way in a complex _expression_... I think IASTProblem[Holder] nodes will appear in the tree, which you may or may not be able to work around.

This is where the experts can help more :)

-- Ed


From: Ryall Ken (Nokia-D-MSW/Austin)
Sent:
Tuesday, June 09, 2009 1:49 PM
To:
cdt-dev@xxxxxxxxxxx
Subject:
[cdt-dev] Using the CDT parser for debug expressions?

I have a question for the folks who have more experience with CDT language parsing than I:

The EDC debugger needs to parse and then evaluate C/C++ expressions. The JDT debugger does this for java expressions using an ASTEvaluationEngine. It looks like it can take a snippet of Java code and create a CompilationUnit, which extends ASTNode. The CompilationUnit accepts a visitor (ASTInstructionCompiler) which produces a compiled version of the _expression_ that the debugger can evaluate. This is all done in org.eclipse.jdt.internal.debug.eval.ast.engine and org.eclipse.jdt.internal.debug.eval.ast.instructions

So I'm wondering if I can take the same approach in CDT. It would need to parse a snippet of code but would usually have a translation unit and project context to consider too.

Thanks for your thoughts,

- Ken
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top