Inconsistent behavior for functions not in any API files
- Dominant language
- Go
- Stars
- 2.2k
- Forks
- 329
- PR merge metrics
- No merged PRs in 30d
Description
When a function pointer is requested, e.g. via eglGetProcAddress, that is not in our API files, we have inconsistent behavior:
in **api_exports.cpp.tmpl**'s `GetSpyProcAddress`, we:
```
GAPID_ERROR("%s will NOT be captured.", name);
return core::GetGlesProcAddress(name, true);
```
i.e. we log and attempt to fallback onto the system's function (that's what the `true` parameter does).
in **installer.cpp** we override `core::GetGlesProcAddress` with `resolveCallback` and only consider returning functions we have previously patched for interception, i.e. functions that are mentioned in the API files.
For functions not in our API files the user sees the following log messages:
```
E/GAPID ( 5561): [gles_exports.cpp:2124] will NOT be captured.
W/GAPID ( 5561): [installer.cpp:115] was requested, but cannot be traced.
```
`resolveCallback` should honor the bypass local flag and attempt to use the original `core::GetGlesProcAddress` to look up functions that were not patched, when the flag is `true`.
It also appears that we never actually call `core::GetGlesProcAddress` with the flag being `false`, so we could just get rid of it.
Contributor guide
Assessment
This issue has not been assessed yet.