Unify module caches#1120
Conversation
Lectem
force-pushed
the
refactor/unify-module-caches
branch
from
663ec72 to
c54b9b8
Compare
|
Rebased due to merge conflicts. |
|
Is there anything holding this PR back? |
I don't have appropriate tools to review the diff (it's practically everything in one commit). Currently looking for some way to print the diff on the paper so I can write some notes. |
…iles in the future
… be used in server, and thus not pointing to current process memory
The name was a bit misleading as it could be mistaken to mean "The cache contains the address" and not as "has an image with this start address". ie: that it could be mistaken to do GetImageForAddress( startAddress ) != nullptr.
Lectem
force-pushed
the
refactor/unify-module-caches
branch
from
9be221a to
aa234d0
Compare
| const auto windirlen = strlen( windir ); | ||
|
|
||
| const auto sz = needed / sizeof( LPVOID ); | ||
| s_krnlCache = (KernelDriver*)tracy_malloc( sizeof(KernelDriver) * sz ); |
There was a problem hiding this comment.
The number of kernel modules is known here. I wonder if this can be preserved with the new interface?
There was a problem hiding this comment.
This is indeed something that bothered me a bit.
I suppose we could either delay the creation of the cache (move it out of CreateImageCaches), or create it with a capacity of 0 (which FastVector currently does not support) and then reserve the new size explicitely.
Do you want me to implement something for this ?
There was a problem hiding this comment.
I'm not sure if it'd be worthwhile to complicate the FastVector implementation.
There was a problem hiding this comment.
Well it would simply require extracting AllocMore into a SetReserve function and remove the assert( capacity != 0 ); but yeah, not sure it's worth the trouble in this specific case. It shouldn't save that much memory nor time anyway.
|
The rest looks good. |
…dd DestroyImageEntry for ImageEntry cleanup
… on other platforms
Image cache will remain potentially unsorted until first access or `Sort` is called explicitely.
This can be CopyStringFast since we allocated the cache on the same thread.
…IMAGE_CACHE Windows is already using a cache, and the only platforms that won't have one for now are those without dl_iterate_phdr.
- Introduce both s_imageCache and s_krnlCache on all platforms, even if unused (will be reused later to unify platforms handling) - This means that what userland images that used to be unsorted are now sorted
Lectem
force-pushed
the
refactor/unify-module-caches
branch
from
aa234d0 to
8ccc76c
Compare
3 participants
This is part of the changes we had in #1009
This is an attempt at unifying the symbol caching mechanisms between windows and linux.
It will later be the base for also storing module debug information (pdb guid, gnu_debug_id, ...).