-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Instruction breakpoints: What is the offset ? #341
Comments
Yes, we should clarify and say "The offset in bytes from..." |
So, this requires the client to parse and understand the 'address' field of the returned instructions from a disassemble request? I guess that's fine, but it does put more constraints on what the "implementation defined" invalid instruction DisassembledInstruction contains. I suggest we state that an address of 0x0 is required for invalid instructions. |
I am not following why it constrains the implementation for an invalid instruction, but I do think it points out one flaw in the spec:
I don't think this should have been listed as implementation defined. I think we need to define the set of allowed formats for this so that one can calculate the size of a CC @andrewcrawley in case I missed something. |
Oh, duh, I should have read this more closely, yes, the |
Right, that's fine - the spec states that |
Can you explain why that would be the case that it would "lead to badness"? |
I just thought it might if the adapter put random number in the address for the invalid instruction. Then the client would try to calculate the offset and end up with a(nother) random number and ask the debugger to put an instruction breakpoint on a random number. There's nothing specific that would be badness here, but it might be better if client is told "0x0 means invalid address" and therefore can just tell the user "That's not a real instruction, you can't put a breakpoint there". It's not a big deal. |
Got it. For programming environments with a flat address space (ex: x86/x64/ARM native debuggers) where you can pretend that the memory space is infinite (ex: subtracting 1 from address 0 just gets you back to
In either case, all instructions have a valid numeric instruction address. For programming environments where the address space isn't so simple: I could potentially see value in some sort of reserved 'invalid value' for |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Hi there. Circling back here, how about these two changes? The aforementioned clarification: interface InstructionBreakpoint {
/**
* The offset from the instruction reference in bytes.
* This can be negative.
*/
offset?: number; Unfortunately allowing the adapter to return less than the requested number of instructions is tricky to do in a backwards-compatible way, but an additional presentation hint for the DisassembledInstruction may help: interface DisassembledInstruction {
/**
* A hint for how to present the source in the UI.
* A value of `invalid` can be used to indicate this instruction is 'filler'
* and cannot be reached by the program. For example, unreadable memory
* addresses may be presented is 'invalid.'
*/
presentationHint?: 'normal' | 'invalid'; |
I wonder if we could allow that using a client-side |
Agree. Both changes seem practical to me. |
In the setInstructionBreakpoints request, we have this:
Is this an instruction offset (like in the disassemble request), or a memory offset (in bytes) like in the readMemory request?
Can we specify it?
The text was updated successfully, but these errors were encountered: