host: treat unbounded range-end as Long.MAX_VALUE (ghidrasql #2/#3/#6) - #16
Merged
Conversation
#2,#3,#6) Range-list RPC handlers fell back to program.getMaxAddress().getOffset() when the range-end was non-positive. The C++ client sends UINT64_MAX for 'all addresses', which decodes to a signed -1 here, so the fallback fired; for programs whose max address is in a low-offset space (EXTERNAL block or offset-0 file sections) the scan window collapsed and range-filtered tables returned 0 rows. Add RuntimeSupport.resolveRangeEnd(), which maps any non-positive end to Long.MAX_VALUE (truly unbounded), and route all 17 list handlers through it. Update cpp/examples to use INT64_MAX.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Host-side companion to 0xeb/ghidrasql#7 — fixes the root cause of ghidrasql issues 0xeb/ghidrasql#2, #3, #6, where range-filtered tables (
funcs,names,instructions,strings,xrefs, …) return 0 rows.Root cause
Every range-list RPC handler fell back to
program.getMaxAddress().getOffset()when the range-end was non-positive:The C++ client sends
UINT64_MAXfor "all addresses", which decodes to a signed-1here, so the fallback fired. For programs whose max address is in a low-offset space (EXTERNAL block, or offset-0 file sections) the window[start, tinyOffset]excluded all real code → 0 rows.Fix
Add
RuntimeSupport.resolveRangeEnd(long), which maps any non-positive end toLong.MAX_VALUE(truly unbounded, nevergetMaxAddress()), and route all 17 list handlers across 6 runtime classes through it (net −45 lines of duplicated boilerplate). Updatecpp/examplesto sendINT64_MAX.Either this or the client-side fix (0xeb/ghidrasql#7) is independently sufficient; shipping both fixes the defect at its source and unblocks clients that still send the old sentinel.
Verification
With an unpatched client (still sending
UINT64_MAX) against this patched host, the helper'sresolveRangeEnd(-1) → Long.MAX_VALUEpath restores results on a triggering Linux ELF fixture: funcs 0→9, names 0→15, instructions 0→77, xrefs 0→50. Extension compiles clean;/bin/lsregression unchanged.