Skip to content

Clarify how addressRange is supposed to be represented in Module event #424

Open

Description

The spec says:

  /**
   * Address range covered by this module.
   */
  addressRange?: string;

In the Module type

It's entirely unclear (from what I gather) how this is supposed to be represented and I haven't been able to find any of the other types, requests or events reference a range of addresses as just one string. I think this probably needs some clarification. Is it supposed to be 0xba5 .. 0xf00 or 0x123:0x456, or 0x123...0x456 or 0x123,+0x80 or any other of the many ways to do it? I think a uniform way would be preferable. But even if the spec doesn't desire a uniform way to represent an address range, it's probably best to at least mention that it's implementation defined.

Activity

  1. connor4312 commented on Aug 4, 2023

    @connor4312
    Member

    I believe in the current state that this is only for display in UI's; it predated any other knowledge of memory in DAP, so the answer would be "whatever the adapter thinks is the best representation."

    However, now that DAP has learned about disassembly and memory, perhaps we should allow associating a range more explicitly for interop with the disassemble request, e.g. two additional properties startAddress and endAddress whose formats are the same as DisassembleRequest.address...

  2. theIDinside commented on Aug 5, 2023

    @theIDinside
    ContributorAuthor

    However, now that DAP has learned about disassembly and memory, perhaps we should allow associating a range more explicitly for interop with the disassemble request, e.g. two additional properties startAddress and endAddress whose formats are the same as DisassembleRequest.address...

    I agree. Also, "bolting this down" probably will mean that less divergence happen here.

    Perhaps a separate new type is to prefer? Like AddressRange: { start: string, end: string }. This way, if there is no range associated (with the module, in this case), the sub object in it's entirety is not serialized. It would also clearly state that, iff there is an addressRange field, both start and end will be defined (since its sub fields are not optional). What do you think?

    That would make the field on Module look like:

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    under-discussionIssue is under discussion for relevance, priority, approach

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions