From: Jan Kiszka <jan.kiszka@siemens.com>
To: Joel Colledge <joel.colledge@linbit.com>
Cc: Leonard Crestez <leonard.crestez@nxp.com>,
Kieran Bingham <kbingham@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] scripts/gdb: fix lx-dmesg when CONFIG_PRINTK_CALLER is set
Date: Fri, 11 Oct 2019 14:38:47 +0200 [thread overview]
Message-ID: <c4ae19a8-54c0-98a6-16bd-48f7ce5689f9@siemens.com> (raw)
In-Reply-To: <20191011122409.23868-1-joel.colledge@linbit.com>
On 11.10.19 14:24, Joel Colledge wrote:
> When CONFIG_PRINTK_CALLER is set, struct printk_log contains an
> additional member caller_id. This affects the offset of the log text.
> Account for this by using the type information from gdb to determine all
> the offsets instead of using hardcoded values.
>
> This fixes following error:
>
> (gdb) lx-dmesg
> Python Exception <class 'ValueError'> embedded null character:
> Error occurred in Python command: embedded null character
>
> Signed-off-by: Joel Colledge <joel.colledge@linbit.com>
> ---
> Changes in v2:
> - use type information from gdb instead of hardcoded offsets
>
> Thanks for the idea about using the struct layout info from gdb, Leonard. I can't see any reason we shouldn't use that here, since most of the other commands use it. LxDmesg has used hardcoded offsets since scripts/gdb was introduced, so I assume it just ended up like that during the initial development of the tool. Here is a version of the fix using offsets from gdb.
That's not unlikely, indeed. lx-dmesg was one of the very first features
I've implemented back then, and it definitely predated things like
CachedType.
>
> scripts/gdb/linux/dmesg.py | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/gdb/linux/dmesg.py b/scripts/gdb/linux/dmesg.py
> index 6d2e09a2ad2f..8f5d899029b7 100644
> --- a/scripts/gdb/linux/dmesg.py
> +++ b/scripts/gdb/linux/dmesg.py
> @@ -16,6 +16,8 @@ import sys
>
> from linux import utils
>
> +printk_log_type = utils.CachedType("struct printk_log")
> +
>
> class LxDmesg(gdb.Command):
> """Print Linux kernel log buffer."""
> @@ -42,9 +44,14 @@ class LxDmesg(gdb.Command):
> b = utils.read_memoryview(inf, log_buf_addr, log_next_idx)
> log_buf = a.tobytes() + b.tobytes()
>
> + length_offset = printk_log_type.get_type()['len'].bitpos // 8
Does bitpos really use a non-int type? Otherwise, plain '/' suffices.
> + text_len_offset = printk_log_type.get_type()['text_len'].bitpos // 8
> + time_stamp_offset = printk_log_type.get_type()['ts_nsec'].bitpos // 8
> + text_offset = printk_log_type.get_type().sizeof
> +
> pos = 0
> while pos < log_buf.__len__():
> - length = utils.read_u16(log_buf[pos + 8:pos + 10])
> + length = utils.read_u16(log_buf[pos + length_offset:pos + length_offset + 2])
Overlong line.
> if length == 0:
> if log_buf_2nd_half == -1:
> gdb.write("Corrupted log buffer!\n")
> @@ -52,10 +59,11 @@ class LxDmesg(gdb.Command):
> pos = log_buf_2nd_half
> continue
>
> - text_len = utils.read_u16(log_buf[pos + 10:pos + 12])
> - text = log_buf[pos + 16:pos + 16 + text_len].decode(
> + text_len = utils.read_u16(log_buf[pos + text_len_offset:pos + text_len_offset + 2])
Here as well. Better use some temp vars to break up the expressions.
Helps with readability.
> + text = log_buf[pos + text_offset:pos + text_offset + text_len].decode(
> encoding='utf8', errors='replace')
> - time_stamp = utils.read_u64(log_buf[pos:pos + 8])
> + time_stamp = utils.read_u64(
> + log_buf[pos + time_stamp_offset:pos + time_stamp_offset + 8])
>
> for line in text.splitlines():
> msg = u"[{time:12.6f}] {line}\n".format(
>
Looks good otherwise.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2019-10-11 12:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 15:03 [PATCH] scripts/gdb: fix lx-dmesg when CONFIG_PRINTK_CALLER is set Joel Colledge
2019-10-10 14:51 ` Joel Colledge
2019-10-10 15:13 ` Jan Kiszka
2019-10-10 19:36 ` Leonard Crestez
2019-10-11 12:24 ` [PATCH v2] " Joel Colledge
2019-10-11 12:38 ` Jan Kiszka [this message]
2019-10-11 12:56 ` Joel Colledge
2019-10-11 14:25 ` [PATCH v3] " Joel Colledge
2019-10-11 15:41 ` Jan Kiszka
2019-10-11 12:47 ` [PATCH v2] " Leonard Crestez
2019-10-11 13:01 ` Joel Colledge
2019-10-11 14:20 ` Leonard Crestez
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=c4ae19a8-54c0-98a6-16bd-48f7ce5689f9@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=joel.colledge@linbit.com \
--cc=kbingham@kernel.org \
--cc=leonard.crestez@nxp.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).