possible gdb agent expression extension

possible gdb agent expression extension

[David Taylor]

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.  

Re: possible gdb agent expression extension

[David Taylor]

David Taylor <dtaylor@emc.com> 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

Re: possible gdb agent expression extension

[Eli Zaretskii]

> Date: Fri, 22 Aug 2014 18:07:38 -0400
> From: David Taylor <dtaylor@usendtaylorx2l.lss.emc.com>
> 
> Hopefully the markup is correct:

I cannot comment on the markup's idea because I don't really
understand what you are trying to say using that markup.  I think the
larger context is missing.

That @result{} at the end, with nothing after it, does look strange:
what "result" does this give?

> @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{}

If this is part of a @table, you will be much better off using "@table
@code", so that 0x?? etc. will be rendered in the appropriate
typeface.  (Btw, what does "0x??" signify?)

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

You cannot stick a code portion in the middle of text just like that,
you should use @smallexample (and then drop the @code parts, as they
are automatically used for text inside @smallexample).

Re: possible gdb agent expression extension

[David Taylor]

Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Fri, 22 Aug 2014 18:07:38 -0400
> > From: David Taylor <dtaylor@usendtaylorx2l.lss.emc.com>

For some strange reason I did not receive the copy sent directly to me
but did receive the copy sent to the list.  Bizarre.

> > Hopefully the markup is correct:
> 
> I cannot comment on the markup's idea because I don't really
> understand what you are trying to say using that markup.  I think the
> larger context is missing.

I was trying to make more concrete the proposal that was previously made
on July 28th and was included in the message for reference.

While I tried to get the markup right, I didn't run texinfo so I figured
I probably botched something somewhere.

> That @result{} at the end, with nothing after it, does look strange:
> what "result" does this give?

I was largely copying snippets I found nearby in the agentexpr.texi
file.  They are of the form:

<agent-opcode> <additional items in the agent byte stream> :
    <items on the stack at start of operation> ==>
    <items on the stack at end of operation>

> > @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{}
> 
> If this is part of a @table, you will be much better off using "@table
> @code", so that 0x?? etc. will be rendered in the appropriate
> typeface.  (Btw, what does "0x??" signify?)

The 0x?? signifies the as yet to be determined opcode for the operation.

In agentexpr.texi the existing descriptions of the operations all had
the hex value of the opcode in parentheses right after the @item
@code{operation name} chunk so I tried to follow it in my message.

I found it hard to read (so I figured others would have a hard time
reading it as well), especially the example you quoted below, so I tried
to also give a version that had less texinfo markup and yet hopefully
preserved the meaning that I was trying to convey.

> > 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}
> 
> You cannot stick a code portion in the middle of text just like that,
> you should use @smallexample (and then drop the @code parts, as they
> are automatically used for text inside @smallexample).

Basically, I want to be able to do something like:

    set variable = value

in an agent expression and have it work.

The rest is details to be worked out.  I'd like to nail down some of the
details.

I'm not concerned with floating point values at the moment, just
integers of various sizes and flavors.  A variable can be in a register
or in memory, So, I need a set register operation and one or more set
memory operations.

We haven't starting implementing this for our new gdb stub, but failing
fires or other higher priority items arising, I expect we will implement
it before the end of the year.  So, I want to nail down

    . what are the operations?
    . what are their respective byte codes?
    . what is the syntax of each of them?
    . what are their semantics?
    . how can GDB determine whether a given remote target supports these
      operations?

Once product ships with a stub containing them it will be hard to change
them.  And I *REALLY* want to remain compatible with standard GDB.

My goal, when the dust settles, is to have some variant of this
functionality in the standard GDB and gdbserver and the same variant in
our new GDB stub.

The people who implemented our old stub and did the bulk of the local
changes to GDB have all left.  Contributing back to the community was
never a priority for them.  I and my boss feel differently.

Hope this helps clarify things.  If questions remain, ask away.

Thanks.

David

Re: possible gdb agent expression extension

[Eli Zaretskii]

> Date: Mon, 25 Aug 2014 10:03:03 -0400
> From: David Taylor <dtaylor@emc.com>
> 
> > That @result{} at the end, with nothing after it, does look strange:
> > what "result" does this give?
> 
> I was largely copying snippets I found nearby in the agentexpr.texi
> file.  They are of the form:
> 
> <agent-opcode> <additional items in the agent byte stream> :
>     <items on the stack at start of operation> ==>
>     <items on the stack at end of operation>

Right, but in your case there's nothing after ==>, which is
unexpected.

Thanks.

Re: possible gdb agent expression extension

[David Taylor]

Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 25 Aug 2014 10:03:03 -0400
> > From: David Taylor <dtaylor@emc.com>
> > 
> > > That @result{} at the end, with nothing after it, does look strange:
> > > what "result" does this give?
> > 
> > I was largely copying snippets I found nearby in the agentexpr.texi
> > file.  They are of the form:
> > 
> > <agent-opcode> <additional items in the agent byte stream> :
> >     <items on the stack at start of operation> ==>
> >     <items on the stack at end of operation>
> 
> Right, but in your case there's nothing after ==>, which is
> unexpected.
> 
> Thanks.

Right.  Like

    if_goto (0x20) offset : a ==>

    goto (0x21) offset : ==>

    trace (0x0c) : addr size ==>

    tracenz (0x2f) : addr size ==>

    printf (0x34) numargs string : ==>

    end (0x27) : ==>

it means that inputs -- if any -- are consumed; nothing is pushed on the
stack.

[Aside: the documentation is missing the ':' on tracenz and printf.  For
that matter, documentation for printf is missing some other stuff, too.]

Re: possible gdb agent expression extension

[Eli Zaretskii]

> Date: Mon, 25 Aug 2014 12:30:02 -0400
> From: David Taylor <dtaylor@emc.com>
> 
>     end (0x27) : ==>
> 
> it means that inputs -- if any -- are consumed; nothing is pushed on the
> stack.

Then please use

      end (0x27) : ==> (nothing)

to make that explicit.