Reorder the DTB tests, since 64-bits have more to match and are likely
more common these days. We've had an instance where a 32-bit DTB was
detected because of a self-referential pointer over a 64-bit DTB leading
to an inaccessible image.
This fixes issue #193.
Context.object accepts a template or a string name (and now a type
flag). Module.object only accepts a string (because a template already
has most of the stuff built in and might as well be passed to the
Context.object constructor).
The gotcha here is the absolute flag, which must now be set
appropriately in all cases *except* where the module is constructed
with an offset of 0 (whereby it will have no impact).
This removes the assertions that checked plugin devs didn't do anything
overly bad in favour of using mypy to ensure appropriate type-checking.
It also moves the ProgressCallback typing information to constants in
order to avoid circular imports (since constants doesn't import
anything).
Originally we found physical offsets for pdbs that matched,
then found potential offsets and tested them against each other.
Now, we find the potential offsets and then look for pdbs at that offset
(technically within a 4Mb block after the start). The scanning is quick
(probably quicker than scanning the whole physical space) and should
catch most pdbs unless they're splayed out in virtual memory.
Since we stack using Mac layers as well as Linux layers, both sets of
banner caches are required. As the cache builders are separate at the
moment, we previously ran banner searches without any banners. This was
bad. It inflated memory hugely and killed the buildbot.
We now bomb out on stacking a Linux or Mac layer unless we have banners
against which to match.
Mike Auty