Re: minor doc fix

[Bart Veer <bartv@ecoscentric.com>]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

    >> Date: Wed, 30 Jul 2008 19:17:02 +0100
    >> From: Bart Veer <bartv@ecoscentric.com>
    >> CC: gdb-patches@sourceware.org
    >> 
    >> The text is not talking about host-side or target-side data
    >> structures. It is describing a protocol, what gets transferred
    >> between host and target for a gettimeofday request, which
    >> happens to be 12 bytes and not 8.

    Eli> Sorry, you lost me. Perhaps I'm confused, but `long' takes 8
    Eli> bytes only on 64-bit Unix machines. Otherwise it's 4 bytes.
    Eli> What am I missing?

That we are talking about a communication protocol which is
independent of any given architecture.

On an embedded target, the target-side stub code can send a packet
Fgettimeofday,<buf1>,<buf2> to the host-side gdb. This is part of the
remote protocol as documented in appendix D, "GDB Remote Serial
Protocol" of the gdb info pages. Communication can happen over a
serial line, a network socket, whatever. The Fgettimeofday packet is
part of the File-I/O Remote Protocol Extension documented in that
appendix.

<buf1> is a pointer to a target-side buffer where gdb should store the
desired information. The protocol specification says that the first 4
bytes of that buffer will be filled with the tv_sec value in
big-endian format, and the next 8 bytes of that buffer will be filled
with the tv_usec value, again in big-endian format. When gdb resumes
the target, target-side code is responsible for converting the
contents of that buffer into appropriate data structures. That may
involve swapping the endianness, truncating the 8 bytes of tv_usec
data to the 4 bytes that are actually required, whatever.

The current documentation states that that target-side buffer only
needs to be 8 bytes, not 12, so anybody implementing target-side code
may reserve insufficient memory. Result: confusion and memory
corruption.

Bart