Skip to content

[SharedCache] Limit sections being added in SharedCache::InitializeHeader to the regions being loaded#6459

Merged
0cyn merged 1 commit into
Vector35:devfrom
WeiN76LQh:dsc-fix-initialize-header-section-adding
Mar 18, 2025
Merged

[SharedCache] Limit sections being added in SharedCache::InitializeHeader to the regions being loaded#6459
0cyn merged 1 commit into
Vector35:devfrom
WeiN76LQh:dsc-fix-initialize-header-section-adding

Conversation

@WeiN76LQh
Copy link
Copy Markdown

The logic before would default to adding a section unless it was from a region in the regionsToLoad argument and its header had already been initialized. However if a user does Load Section by Address then there's only one region in regionsToLoad. All sections not in that region would be automatically added, even if they had already been or the user hadn't requested them to be loaded.

@WeiN76LQh
Copy link
Copy Markdown
Author

I actually wanted to do a lot more with this PR in regards to section loading but I'm unsure what the desire is and a reasonable amount of code will need modifying.

Currently the user can Load Section by Address with a right-click action but this is misleading as it results in a segment being loaded which can load multiple sections, in some cases, quite a few. Also when right-clicking a address for memory which has not been loaded the user is offered to load a segment not a section.

It makes sense to be more granular as some segments do contain a number of sections but this will realistically require the metadata to be modified to track when a memory region (representing an image segment) has only be partially loaded due to not all of its sections being loaded.

I think either Load Section by Address should become Load Segment by Address, to more accurately represent what will happen, or the code should be modified to only load a section. The latter, to me, is more desireable. Additionally it would make sense to modify the right-click on an unloaded memory address to offer to load a section rather than a segment.

This is personal opinion so it would be good to hear what the devs think o this before I push a PR.

@fuzyll fuzyll requested a review from 0cyn March 3, 2025 19:29
@fuzyll fuzyll added this to the Gallifrey milestone Mar 3, 2025
…eader` to the regions being loaded

The logic before would default to adding a section unless it was from a region in the `regionsToLoad` argument and its header had already been initialized. However if a user does `Load Section by Address` then there's only one region in `regionsToLoad`. All sections not in that region would be automatically added, even if they had already been or the user hadn't requested them to be loaded.
@0cyn 0cyn force-pushed the dsc-fix-initialize-header-section-adding branch from 9f32213 to 3d73ec6 Compare March 18, 2025 10:24
@0cyn 0cyn merged commit 3d73ec6 into Vector35:dev Mar 18, 2025
@0cyn
Copy link
Copy Markdown
Contributor

0cyn commented Mar 18, 2025

I went ahead and merged this as the fix is solid.

I think either Load Section by Address should become Load Segment by Address, to more accurately represent what will happen, or the code should be modified to only load a section. The latter, to me, is more desireable. Additionally it would make sense to modify the right-click on an unloaded memory address to offer to load a section rather than a segment.

I think it would be good to make an issue regarding your thoughts on this to prompt further discussion, I've been moving towards segment loading as it made the code much easier to deal with (and left this feature out of the KernelCache loader entirely.)

If we do target single section rather than segment, a large swathe of stuff needs to be rethought to work with sections, e.g. how we build the SharedCacheCore::MemoryRegion map (currently it's by segment) and how we interact with BinaryNinjaAPI::MemoryMap (which creates non-file-backed Segments).

The language absolutely needs updated in certain areas.

I'd love to get more input from people using this specific feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants