Re: [PATCH 9/9] gdb/testsuite/dap: fix gdb.dap/basic-dap.exp disassembly test for PIE

[Simon Marchi <simark@simark.ca>]

On 1/25/23 17:10, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>>>>> {... {"memoryReference": "0x115d"
> 
> Simon> The problem is that the PC to disassemble is taken from the breakpoint
> Simon> insertion response, which happens before running.  With a PIE
> Simon> executable, that PC is unrelocated, but the disassembly request happens
> Simon> after relocation.
> 
> This is an odd one.  It isn't super clear when memory references are
> invalidated.  (The spec doesn't even define what a memory reference is.)

I'm not sure what you mean.  The same could happen in a regular GDB
test, if you grabbed a function's address, started the program, and
tried to disassemble at that address.  I don't expect GDB to be able to
do anything with the unrelocated address obtained before running.

Since there isn't a DAP event that says when symbols have changed
(AFAIK), I think DAP clients have to assume that any symbol address may
be invalid after resuming the program.

> Simon> I chose to fix this by watching for a breakpoint changed event giving
> Simon> the new breakpoint address, and recording the address from there.  I
> Simon> think this is an interesting way to fix it, because it adds a bit of
> Simon> test coverage, I don't think these events are checked right now.
> 
> This seems pretty good to me.
> 
> Simon>  - Do the disassembly by symbol instead of by address.
> 
> I don't think this is possible in DAP.  One of the many holes.

When I saw this in the DisassembleArguments DAP structure:

  /**
   * Memory reference to the base location containing the instructions to
   * disassemble.
   */
  memoryReference: string;

I assumed that memoryReference could be pretty much anything that
resolves to an address, essentially the same thing you could pass to
GDB's disassemble command.  But that's just my interpretation of it.

Simon