dwitte@gmail.com Reporter
	Description • 15 years ago

For bug 507711, we want to produce an accurate callgraph that includes information like "what implementors exist for a given xpcom interface". (More precisely, "for this virtual method call, there are 4 relevant implementations, and they are...".)

Given that such implementations could live in JS, being able to include this information is essential to producing a complete callgraph. The ultimate goal would be merging a JS callgraph with the C/C++ one. However, simply being able to find JS implementors of xpcom interfaces would go a long way toward this. In the example above, one could then say "for this virtual method call, there are 4 relevant implementations, and one of them is JS". If one were doing an analysis that depended on having an accurate graph, knowing that there's a possibility of calling into JS would at least let you abort, or possibly do something more intelligent.

	Joshua Cranmer [:jcranmer]
	Comment 1 • 15 years ago

This is one of the things that I've planned to work on (or better yet, for someone else to work on :) ). I need to look more in how xpconnect works, but my plan is something along these lines:

1. Any time you see a .QueryInterface, assume it's an XPCOM object and start XPCOM type analysis.
2. All XPCOM objects support nsISupports.
3. For any function call or attribute access from an XPCOM object, find the mapping from the idl files somehow (I haven't yet decided) to deduce the types of other objects. Recursively deduce types from other people.
4. Recognize global variables from certain contexts (e.g., window in HTML files).

I bet this is nowhere near sufficient, but it's a start.

	Ben Turner (not reading bugmail, use the needinfo flag!)
	Comment 2 • 15 years ago

(In reply to comment #1)
> 1. Any time you see a .QueryInterface, assume it's an XPCOM object

XPConnect will actually make something an XPCOM object even without a QI function.

	David Dahl :ddahl
	Comment 3 • 15 years ago

(In reply to comment #2)
> (In reply to comment #1)
> > 1. Any time you see a .QueryInterface, assume it's an XPCOM object
> 
> XPConnect will actually make something an XPCOM object even without a QI
> function.

Perhaps we should make a list of how to parse or recognize XPCOM objects that are instantiated in JS in this bug?

	David Dahl :ddahl
	Comment 4 • 15 years ago

dwitte:

just curious if you can post the sqlite schema you are using to track the native code functions/classes/etc.

	dwitte@gmail.com Reporter
	Comment 5 • 15 years ago

Yep, it's at https://developer.mozilla.org/en/Callgraph/Schema_Reference.

	Ed Lee :Mardak
	Comment 6 • 15 years ago

Would it make more sense to look for known XPCOM objects with methods being called with XPCOM object as arguments?

For example, I have this piece of code..

Svc.Bookmark.runInBatchMode({
  runBatched: callback
});

If you can figure out Svc.Bookmark is nsINavBookmarksService (because it was getService'd or QI'd earlier), you know nsINavBookmarksService.runInBatchMode takes a nsINavHistoryBatchCallback. So the anonymous object I'm passing in is probably that type -- even though I didn't bother writing a QI method for the object.