Subscribe via feed.

Current symbol scanning issues

Posted by PatrickvL on 2010/12/06 – 01:27
Perhaps this post is more a public note-to-self, but it doesn’t hurt sharing this information.
Recently, I looked into our symbol scanning engine again, as it’s not yet performing as well as I would have wanted.
What I discovered is that our scanning is hindered by three things:
  1. Not having version-exact patterns. We approximate with other versions we do have patterns for, but length- and content differences cause incorrect behaviour. (I don’t need to remind you that we would really *love* to get more XDK patterns!)
  2. Identical patterns with different names. These are currently aliassed together into one symbol, but in reality each of those can exists separately. Because we register only one of these, the other locations stay unrecognized and can even trigger a failure when detecting higher level symbols.
  3. A new category has sprung up last week : Some libraries (like libcmt) contain multiple symbols with the same name, but with a different pattern! This causes yet another type of failure on higher-level symbols, as we only keep one declaration for any given symbol name – so a reference to the second declaration will always fail.
I don’t know yet how we’re going to fix these issues, but at least we now know what issues we’re dealing with in this very important piece of code!

This post is under “Dxbx development” and has no respond so far.
If you enjoy this article, make sure you subscribe to my RSS Feed.