switch table confused as function start about pharos HOT 3 CLOSED

Interesting test case. I think the explanation of the behavior goes something like this... The function bar is not called from anywhere, so the partitioner must make some guesses to discover it. The "align 10h" at 0x40103F is probably actually some form of NOP instruction, although I've not actually confirmed this. Then when we come to the unknown "data block" beginning around 0x040102B(?), we attempt to make code, which succeeds in creating something vaguely "bar-like" but at the wrong address. We would get better results if bar() was actually called from somewhere. Arguably, if bar() is not called from anywhere, is there really a function there? Obviously there is, but it's also not too surprising that it's hard to find correctly. :-)

from pharos.

Just a reduced test case, in the original code it's probably used. But may have been virtual functions.

from pharos.

I was going to say "called or used in a virtual function table", but then I realized that the partitioner doesn't really know about virtual function tables, so the problem will persist when the only reference to the function is in a virtual table and it is not called directly elsewhere. :-( The fix for that problem is much more complicated, and involves freeing our framework from the idea that partitioning occurs before analysis, and shifting to a model where partitioning occurs during analysis. Sadly, that's not likely to happy any time soon...

from pharos.