In #1547, we added the capability for BAP to load multiple shared libraries into a single project. The problem is, we left out the behavior where these libraries should be loaded at address spaces that don't overlap with each other (or the main executable). On top of that, the memories of each library weren't being loaded by Primus, which limited the usefulness of this feature.
This PR allows BAP to, on the fly, decide where to load the libraries in memory. To do this, we extended the Image.Loader interface to be parameterized by the Knowledge Base, such that we can suggest a Theory.Unit.bias for the library file being loaded.
While we're at it, we can extend the LLVM ELF loader to look at data and R_*_RELATIVE relocations, such that we can fix them up in the Primus loader. The motivation for this is that undoubtedly the shared libraries will need to be relocated, so accesses to relocation symbols and so on during a Primus run will need them to be fixed in order to get the correct behavior.
In #1547, we added the capability for BAP to load multiple shared libraries into a single project. The problem is, we left out the behavior where these libraries should be loaded at address spaces that don't overlap with each other (or the main executable). On top of that, the memories of each library weren't being loaded by Primus, which limited the usefulness of this feature.
This PR allows BAP to, on the fly, decide where to load the libraries in memory. To do this, we extended the
Image.Loaderinterface to be parameterized by the Knowledge Base, such that we can suggest aTheory.Unit.biasfor the library file being loaded.While we're at it, we can extend the LLVM ELF loader to look at data and
R_*_RELATIVErelocations, such that we can fix them up in the Primus loader. The motivation for this is that undoubtedly the shared libraries will need to be relocated, so accesses to relocation symbols and so on during a Primus run will need them to be fixed in order to get the correct behavior.