This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: possible gdb agent expression extension


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]