Re: possible gdb agent expression extension

David Taylor <[email protected]> wrote:

> We're thinking of extending gdb agent expreswions by adding additional
> bytecodes.  Before doing this I'd like to determine whether the idea of
> doing this would be looked upon favorably and what form it should take.
> 
> [One of our current goals with regard to GDB is to use stock GDB sources
> as much as possible and to only make changes that are either bug fixes
> or extensions that when contributed back are likely to be looked upon
> favorably in concept and hopefully in implementation.]
> 
> We would like to be able to set variables using byte code expressions.
> In practice this means being able to set memory and being able to set
> registers.  There are no byte code for either of these.
> 
> For setting registers, a new opcode 'setreg'.  Like 'reg' the next two
> bytes of the bytecode stream are the register number.  Top of expression
> stack is the value to set it to.  And the top of the expression stack is
> popped.
> 
> For setting memory, two possibilities come to mind:
> 
> . either, one opcode 'set' or 'setmem' with next byte in byte code
> stream saying how big a chunk of memory to set, with top two values on
> expression stack being the address to set and the value to set it to.
> 
> . or, four new opcodes (similar to 'ref' and 'const') -- set8, set16,
> set32, and set64 with, again, top two values on expression stack being
> the address to set and the value to set it to.
> 
> Is this something people would like to see added?
> 
> Which approach do people feel is better?  Which should be top of stack?
> Address?  Or value?  And should they be popped?
> 
> As I have other, higher priority, items to work on, it will likely be
> awhile before I start on this.  

I never saw any responses to this.  My inclination is to make setmem
like const and ref and have 4 versions one each for 8, 16, 32, and 64
bits -- though I could be persuaded that there should be just one which
takes the bit size as an argument.

Hopefully the markup is correct:

@item @code{setmem8} (0x??): @var{addr} @var{value} @result{}
@item @code{setmem16} (0x??): @var{addr} @var{value} @result{}
@item @code{setmem32} (0x??): @var{addr} @var{value} @result{}
@item @code{setmem64} (0x??): @var{addr} @var{value} @result{}

Pop an address @var{addr} and a value @{value} from the stack.  For
bytecode @code{setmem}@var{n}, set the @var{n}-bit value at @var{addr}
to the least significant @var{n}-bits of @var{value}.  Ignoring
architecture pointer alignment issues, it is as if the operation

*@code{uint}@var{n}@code{_t}@var{addr} = @code{uint}@var{n}@code{_t}@var{value}

What I'm trying to say is:

setmem8 (0x??):  <addr> <value> ==>
setmem16 (0x??): <addr> <value> ==>
setmem32 (0x??): <addr> <value> ==>
setmem64 (0x??): <addr> <value> ==>

Pop an address <addr> and a value <value> from the stack.

For bytecode setmem<n>, set the <n>-bit value at <addr> to the least
significant <n>-bits of <value>.  Ignoring architecture pointer alignment
issues, it is as if the operation

    *(uint<n>_t *)addr = (uint<n>_t)<value>

was performed.

If attempting to set memory address <addr> to <value> would cause a
processor exception, terminate with an error.

Similarly, for setreg:

@item @code{setreg} (0x??) @var{regnum}: @var{value} @result{{}

Or:

setreg (0x??) <regnum>: <value> ==>

Pop <value> off the stack and set <regnum> to <value>.

If register <regnum> does not exist or cannot be set, terminate with an
error.

<regnum> is a 16 bit value with the same interpretation as for the reg
operation.

Looking at gdb/common/ax.def, the last opcode that appears to be
allocated is 0x34 for printf.  So, how about opcodes:

    0x35 for setmem8
    0x36 for setmem16
    0x37 for setmem32
    0x38 for setmem64
    0x39 for setreg

?

Also, should there be a string to place within the qSupported response
to tell GDB that these operations are supported?  Maybe:

    SetOps+

?  Or something else?

David
--
dtaylor at emc dot com