From: Tom Tromey <tromey@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Handle \r\n in gdbreplay
Date: Thu, 21 Feb 2019 16:07:00 -0000 [thread overview]
Message-ID: <87y369jfby.fsf@tromey.com> (raw)
In-Reply-To: <83sgwhfa1o.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Feb 2019 17:14:43 +0200")
>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
Eli> I'm okay with treating \r\n as a single \n, but do we really want to
Eli> treat a single \r as if it were \n? I thought systems which used that
Eli> EOL convention are not really widespread, to say the least.
I normally handle \r this way out of habit I suppose. It doesn't matter
that much to me, I guess \r isn't likely to be seen or made by accident.
Tom
commit eb7112d0f11809c25f415fa4f48aa6abe5fd84a4
Author: Tom Tromey <tromey@adacore.com>
Date: Wed Feb 20 14:29:23 2019 -0700
Handle \r\n in gdbreplay
I tried gdbreplay yesterday, but the remotelogfile I received was made
on Windows, so the lines were terminated with \r\n rather than plain
\n.
This patch changes gdbreplay to allow \r\n line termination when
reading the log file.
gdb/gdbserver/ChangeLog
2019-02-21 Tom Tromey <tromey@adacore.com>
* gdbreplay.c (logchar): Handle \r\n.
diff --git a/gdb/gdbserver/ChangeLog b/gdb/gdbserver/ChangeLog
index e9fe5ab03f0..be0d0e293b2 100644
--- a/gdb/gdbserver/ChangeLog
+++ b/gdb/gdbserver/ChangeLog
@@ -1,3 +1,7 @@
+2019-02-21 Tom Tromey <tromey@adacore.com>
+
+ * gdbreplay.c (logchar): Handle \r\n.
+
2019-02-07 Alan Hayward <alan.hayward@arm.com>
* linux-low.c (linux_attach): Add process before lwp.
diff --git a/gdb/gdbserver/gdbreplay.c b/gdb/gdbserver/gdbreplay.c
index 26a55533ff6..bda8095839c 100644
--- a/gdb/gdbserver/gdbreplay.c
+++ b/gdb/gdbserver/gdbreplay.c
@@ -316,10 +316,26 @@ logchar (FILE *fp)
int ch2;
ch = fgetc (fp);
- fputc (ch, stdout);
- fflush (stdout);
+ if (ch != '\r')
+ {
+ fputc (ch, stdout);
+ fflush (stdout);
+ }
switch (ch)
{
+ /* Treat \r\n as a newline. */
+ case '\r':
+ ch = fgetc (fp);
+ if (ch == '\n')
+ ch = EOL;
+ else
+ {
+ ungetc (ch, fp);
+ ch = '\r';
+ }
+ fputc (ch == EOL ? '\n' : '\r', stdout);
+ fflush (stdout);
+ break;
case '\n':
ch = EOL;
break;
next prev parent reply other threads:[~2019-02-21 16:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 14:05 Tom Tromey
2019-02-21 15:14 ` Eli Zaretskii
2019-02-21 16:07 ` Tom Tromey [this message]
2019-02-21 16:12 ` Paul Koning
2019-02-27 18:49 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y369jfby.fsf@tromey.com \
--to=tromey@adacore.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox