This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: minor doc fix
>>>>> "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