[Lldb-commits] [PATCH] D95712: [lldb/bindings] Add Python ScriptedProcess base class to lldb module

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Unfortunately I don't have the bandwidth to review this, though I feel that this should have a wider discussion, given that its destined to become a pretty big chunk of our public immutable api surface.
Some questions to seed that discussion:

  get_num_memory_regions() -> int:
  get_memory_region_at_index(idx: int) -> lldb.SBMemoryRegionInfo:

This means that the implementation needs to know the exact count of memory regions at any given moment. Elsewhere, we've handled this by having a single api like `get_memory_region_containing_address`. This permits (but doesn't force) the implementation to be lazy in calculating the memory regions, and the caller can still enumerate the memory regions by starting with `get_memory_region_containing_address(0)` and continuing by `get_memory_region_containing_address(prev_region.base + prev_region+size)`. I think we should do the same here.

  get_num_threads() -> int:
  get_thread_at_index(idx: int) -> Dict:

This suffers from the same problem, though the solution is not that simple. But given that, not too long ago, we've (me&Jim) had a long discussion about how materializing all the threads all the time is prohibitively expensive, it might be good to elaborate on how exactly is this supposed to work (must the implementation always return all threads, or can it have threads disappear temporarily, etc.)

  get_register_for_thread(tid:int) -> Dict:

I guess this should be at least get_register**s**_for_thread

  read_memory_at_address(addr:int) -> lldb.SBData:

How much memory is this supposed to read?

  can_debug() -> bool:

What's the use case for this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95712/new/

https://reviews.llvm.org/D95712