This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
remote/1806: GDB doesn't recover optimially when ACK is lost
- From: jon at beniston dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 5 Nov 2004 14:56:14 -0000
- Subject: remote/1806: GDB doesn't recover optimially when ACK is lost
- Reply-to: jon at beniston dot com
>Number: 1806
>Category: remote
>Synopsis: GDB doesn't recover optimially when ACK is lost
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Fri Nov 05 14:57:59 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: jon@beniston.com
>Release: gdb-6.0
>Organization:
>Environment:
>Description:
When using the remote serial protocol, if an ACK goes missing, the target stub will continually respond to any future character with the last sent packet. This results in "Packet instead of Ack, ignoring it" being printed (Line 4228 in remote.c). While remote.c correctly ignores the packet, is just currently ends up resending the new packet after timing out. This means progress will never be made, as the target will always respond with the old response instead of an ack.
>How-To-Repeat:
>Fix:
When GDB receives a packet instead of an ACK, it should skip the the redundant packet, ack it, and then resend.
>Release-Note:
>Audit-Trail:
>Unformatted: