Re: GDB Remote Protocol Extension - Linux VMCOREINFO - Request for Feedback

[Andrew Burgess via Gdb <gdb@sourceware.org>]

Stephen Brennan via Gdb <gdb@sourceware.org> writes:

> Tom Tromey <tom@tromey.com> writes:
>>>>>>> Luis Machado via Gdb <gdb@sourceware.org> writes:
>>
>>>> To sum up, my specific questions are:
>>>> 
>>>> 1. What is the maximum protocol packet size, if any?
>>
>>> It is hardcoded by gdb, but the remote can also specify that, but...
>>
>>>> 2. Would this functionality be better implemented in a single "q
>>>> linux.vmcoreinfo" packet, or as a "qXfer" packet?
>>
>>> ... we have packets like qXfer that can handle multi-part transfers. So the
>>> packet size is not a critical concern anymore, and it is best to use this
>>> newer mechanism, if the usage fits the packet structure.
>>
>> Agreed, qXfer is the way to go.
>
> Thank you Tom & Luis for confirmation, qXfer seems appropriate. With
> that approach the buffer size is not really a concern: we can simply use
> the minimum of the requested read size, and the stub's buffer size. So
> long as clients use multiple requests until the data is fully read.
>
> While the "os" object also sounds like a good place to put this (e.g.
> within a new annex), it seems like that contains XML-formatted data with
> well-understood schema and semantics. The vmcoreinfo is free-form text
> (generally of a "key=value" format), so it probably should be a separate
> object.
>
> So I think we would prefer to add an object type, e.g. named "vmcoreinfo".
> (But please do speak up if this sounds like a mistake)
>
>> If you're adding a new object type, a patch to the manual would be good.
>
> I'll definitely include a patch for the manual in the plan for this.
> Another patch I'd like to write is to allow GDB's server to expose this
> object type when the target is an ELF core dump with a VMCOREINFO note.
> We're hoping for this to useful for all debuggers, not just drgn.

Hi Stephen,

I took a look at the wiki page and it seems like initially at least,
your plan is to make the information from vmcoreinfo available via a new
'info' command.

It is possible to send remote packets through GDB's Python API[1].  And
of course, the Python API allows for new commands to be created[2].
There is a test in GDB's test suite that makes use of the packet sending
API, and it happens to send a qXfer packet[3].

I say all this not to put you off contributing a patch to core GDB, but
if what you want is a new user command which will send a packet to a
remote target and process the results, then it should be possible to
implement this as a Python extension.

The benefits of using a Python API are that you can ship the extension
with the kernel, so if/when the vmcoreinfo changes you can easily update
the extension.  At the very least, it allows you to prototype your
commands before having to submit patches to GDB core.

I have included below a very simple example that implements 'info stuff'
which just displays the 'threads' information from a remote target.
Place the code into 'cmd.py', then from GDB 'source cmd.py', after which
you can 'info stuff' and 'help info stuff'.

If this is an approach that might be of interest then I'm happy to help
in any way I can, just drop questions on the mailing list.

Thanks,
Andrew


[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Connections-In-Python.html
[2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/CLI-Commands-In-Python.html
[3] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/testsuite/gdb.python/py-send-packet.py;hb=HEAD#l100

--

def bytes_to_string(byte_array):
    res = ""
    for b in byte_array:
        b = int(b)
        if (b >= 32 and b <= 126) or (b == 10) :
            res = res + ("%c" % b)
        else:
            res = res + ("\\x%02x" % b)
    return res


def get_stuff(conn, obj):
    assert isinstance(conn, gdb.RemoteTargetConnection)
    start_pos = 0
    len = 10
    output = ""
    while True:
        str = conn.send_packet("qXfer:%s:read::%d,%d" % (obj, start_pos, len))
        str = bytes_to_string(str)
        start_pos += len
        c = str[0]
        str = str[1:]
        output += str
        if c == "l":
            break
    return output


class InfoStuffCommand (gdb.Command):
    """
    Usage:
      info stuff

    Shows the remote targets thread information.
    """

    def __init__ (self):
        gdb.Command.__init__ (self, "info stuff", gdb.COMMAND_DATA)

    def invoke(self, args, from_tty):
        inf = gdb.selected_inferior()
        conn = inf.connection
        if not isinstance(conn, gdb.RemoteTargetConnection):
            raise gdb.GdbError("not on a remote connection")
        string = get_stuff(conn, "threads")
        print("Target thread information:")
        for line in string.splitlines():
            print("  %s" % line)

InfoStuffCommand ()