Clarify how addressRange is supposed to be represented in Module event

[theIDinside]

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.

[connor4312]

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...

[theIDinside]

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?