From: Leonard Crestez <leonard.crestez@nxp.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kieran@ksquared.org.uk>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] scripts/gdb: lx-dmesg: Use errors=replace for decoding
Date: Fri, 23 Jun 2017 20:29:04 +0300 [thread overview]
Message-ID: <1498238944.32344.34.camel@nxp.com> (raw)
In-Reply-To: <cb6751a5-4a14-01b9-785f-48bfa67d2c89@siemens.com>
On Fri, 2017-06-23 at 18:02 +0200, Jan Kiszka wrote:
> On 2017-06-23 16:20, Leonard Crestez wrote:
> >
> > It is never desirable lx-dmesg to fail on string decoding errors,
> > not
> > even if the log buffer is corrupt.
> >
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > ---
> > scripts/gdb/linux/dmesg.py | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/gdb/linux/dmesg.py
> > b/scripts/gdb/linux/dmesg.py
> > index 6f8d2b2..d0cac58 100644
> > --- a/scripts/gdb/linux/dmesg.py
> > +++ b/scripts/gdb/linux/dmesg.py
> > @@ -52,13 +52,13 @@ class LxDmesg(gdb.Command):
> > continue
> >
> > text_len = utils.read_u16(log_buf[pos + 10:pos + 12])
> > - text = log_buf[pos + 16:pos + 16 + text_len].decode()
> > + text = log_buf[pos + 16:pos + 16 +
> > text_len].decode(errors='replace')
> pep8 should complain.
>
> >
> > time_stamp = utils.read_u64(log_buf[pos:pos + 8])
> >
> > for line in text.splitlines():
> > gdb.write("[{time:12.6f}] {line}\n".format(
> > time=time_stamp / 1000000000.0,
> > - line=line))
> > + line=line.encode(errors='replace')))
> You only talk about "decoding" in the commit log, but here you encode
> back. An short explanation why this is also needed would be nice.
>
Apparently .decode(errors='replace') will return an unicode string
where invalid characters are replaced with U+FFFD REPLACEMENT
CHARACTER. Attempting to encode that back to the default ascii encoding
of python2 throws an error, using errors='replace' results in a '?'
instead.
See: https://docs.python.org/2/library/codecs.html#codec-base-classes
In python3 the default encoding seems to be utf8 and errors='replace'
is not obviously required on the encode step.
I don't actually have a gdb version compiled with python3 support and
don't know if gdb.write always properly handles unicode in all cases.
Perhaps it might be better to also explicitly specify 'utf8' as the
encoding?
Linux does occasionally print unicode, for example the jffs2 driver
shows an copyright symbol at startup. Using errors='replace' everywhere
on python2 results in this output from lx-dmesg:
[ 0.367578] jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
In theory if we use decode('utf8', errors='replace') and encode('utf8')
then errors='replace' would not be required on the encode side.
Honestly for debug code it might be preferable to do the safest
possible thing and go 'ascii' everywhere.
--
Regards,
Leonard
next prev parent reply other threads:[~2017-06-23 17:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-23 14:20 [PATCH 1/2] gdb/scripts: lx-dmesg: Cast log_buf to void* for addr fetch Leonard Crestez
2017-06-23 14:20 ` [PATCH 2/2] scripts/gdb: lx-dmesg: Use errors=replace for decoding Leonard Crestez
2017-06-23 16:02 ` Jan Kiszka
2017-06-23 17:29 ` Leonard Crestez [this message]
2017-06-23 20:04 ` Jan Kiszka
2017-06-23 16:02 ` [PATCH 1/2] gdb/scripts: lx-dmesg: Cast log_buf to void* for addr fetch Jan Kiszka
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=1498238944.32344.34.camel@nxp.com \
--to=leonard.crestez@nxp.com \
--cc=jan.kiszka@siemens.com \
--cc=kieran@ksquared.org.uk \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.