ExtObject extends the SDObject structure with helper
methods.
Intervals are used for memory region tracking.
Change-Id: I38198c0a096ed838d527b6526216fb28326ebc89
* Most functions - including pthreads, malloc, free, etc are not safe to use in
signal handlers. So we use a simple spin-lock and manual linked-list to manage
our list of PIDs to wait on.
* Hooking is now done the same way across platform, with different OS
implementations.
* Regardless of how exactly hooks are implemented, we register libraries to hook
and functions to hook within those libraries, and provide a location to store
the original/onwards function pointer. This allows hooking to work whether
it's done using import hooking that doesn't modify target libraries (so using
dlsym or GetProcAddress will return the same value for the onwards function
pointer) or whether it's implemented with prologue patching and trampolines,
where we'd create an infinite loop if we did that.
* We also provide stronger guarantees - the original function pointers will
_always_ be made available as soon as the library is loaded, whether hooked or
not, no exceptions. This means less uncertainty in hooking code about when or
how onward functions will be available.
* OS-specific hook functions are changed to just be implementations of
LibraryHooks functions rather than indirected through macros and pre-processor
definitions.
* In this commit we provide some temporary functions providing the old interface
to reduce churn - the library-specific hook code will be updated shortly after
* This library will be used to replace the PLT hooking for most core
functions, and is generally more reliable. It still fails in some
cases though when the target function is not patchable.
* To build, it requires LLVM. See README.md for instructions on building
a compatible LLVM for use.
* This lets us add the debuggable flag we need, at the cost of needing
to re-sign the APK. It works in many cases although sometimes it does
fail - but this is provided just as a 'best effort' and not as a
recommended workflow.
* This is based on the GAPID method of injection, using the same steps
to connect with JDWP and debug the application, breakpointing on key
init-time steps to patch vulkan layer search paths and load libraries
from our installed apk.
* We diverge by then using PLT hooks instead of trampolines to hook the
EGL/GL calls - and so we also hook dlopen.
* This should work on any debuggable application - not currently checked
but does not replace/break any of the previous injection, which can
still work.
* On windows, the change in a global GIT_COMMIT_HASH define in each
project needing it meant a full rebuild every time the commit changed.
* Ideally we'd set the define only on one file in each project, but
MSBuild doesn't seem to support that. Instead we make a new tiny
project that compiles a single cpp exporting a global var, and
reference that global var in each other project.
* We enforce a naming scheme more strongly - types, member functions,
and enum values must be UpperCaseCamel, and member variables must be
lowerCaseCamel. No underscores allowed.
* eventId not eventID or EID, and Id preferred to ID in general. Also
for resourceId.
* Removed some lingering hungarian m_Foo naming.
* Some pipeline state structs that are almost identical between the
different APIs are pulled out into common structs. Where something
doesn't make sense (e.g. viewport enable for vulkan) it will just be
set to a sensible default (in that case always true).
* Changed scissors to be x/y & width/height instead of sometimes
left/top/right/bottom
* Abbreviations are discouraged, e.g. operation not op, function not
func.
* The new system contains the ability to export serialised data to a
structured form in memory - and conversion back to serialised bytes.
* This will allow offline transformations/visualisation of capture files
as well as more rich representations of API calls in the UI.
* Likewise it enables a number of optimisations such as the ability to
write straight from mapped API memory to disk via a compressor,
without any intermediate copies.
* The commits following this add a new refactored serialisation system.
As a balance between readability of individual commits and ability to
bisect/compile at interim steps, the individual API back-ends are
disabled in this commit, so that after the serialisation system is
committed the project compiles again as soon as possible.
* However this is of course not much use in itself as then the code
can't function usefully. The drivers are re-enabled as each one is
updated to the new system, so at least the codebase should stay
compiling, even if each individual API may not yet be functioning.
* The new serialiser system will not handle the container file itself,
so we've separated it out to deal in sections and stream I/O to read
from and write to sections.
* We also add the ability to choose the compression scheme for a section
instead of always using LZ4. LZ4 will still be used on the fly for
fast write performance, but then RDC files can be re-compressed for
savings offline.
* This I/O will form the basis of the new serialiser - it will simply
read to or write from one of these I/O streams. Then that stream can
come from a file, go to a memory buffer, or go through a compressor
or decompressor transparently.
* It also allows a unified way of writing over sockets instead of
needing special socket helper functions.
* With this commit, the code isn't used aside from in tests.
* Note that while this is public and uses std::string, because it's a
template with specialisations in a .inl the string never crosses a
module boundary - each including module has its own implementation.
* This will be used as part of the upcoming serialisation refactor.
* Some POD structs are still given ToStr implementations as we haven't
yet switched over the serialisation system to expect all structs to
have serialise functions.
* We have some special handling to allow SWIG wrapping of these types:
SDFile owns the chunks and buffers within, and each object owns its
children. Copying is disallowed except from SWIG where we assume the
wrapper is handling lifetime management for its objects externally.
* For the most part the interface is stl-compatible, but we have a few
little changes of our own for convenience.
* This class is still needed after deleting the C# UI, because we don't
want to pass C++ stl structs over module boundaries and possibly run
into hard to diagnose incompatibilities.
* The directories are flattened since the #include paths aren't
relative and instead just #include "file.h". The recommended
solution is just to flatten the directory structure.
akharlamov