From: Johannes Berg <johannes@sipsolutions.net>
To: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Kieran Bingham <kbingham@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>
Cc: chinwen.chang@mediatek.com, qun-wei.lin@mediatek.com,
linux-mm@kvack.org, linux-modules@vger.kernel.org,
casper.li@mediatek.com, akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v2 1/8] scripts/gdb/symbols: add specific ko module load command
Date: Tue, 12 Sep 2023 11:41:29 +0200 [thread overview]
Message-ID: <c44b748307a074d0c250002cdcfe209b8cce93c9.camel@sipsolutions.net> (raw)
In-Reply-To: <20230808083020.22254-2-Kuan-Ying.Lee@mediatek.com>
On Tue, 2023-08-08 at 16:30 +0800, Kuan-Ying Lee wrote:
> Add lx-symbols <ko_path> command to support add specific
> ko module.
I'm not sure how this was supposed to work? It should have updated the
documentation, but more importantly, it shouldn't have broken the
documented usage of this command:
The kernel (vmlinux) is taken from the current working directly. Modules (.ko)
are scanned recursively, starting in the same directory. Optionally, the module
search path can be extended by a space separated list of paths passed to the
lx-symbols command.
Note how that talks about a "space separated list of paths" for which
clearly a single path seems like it should be accepted?
> @@ -138,6 +139,19 @@ lx-symbols command."""
> else:
> gdb.write("no module object found for '{0}'\n".format(module_name))
>
> + def load_ko_symbols(self, mod_path):
> + self.loaded_modules = []
> + module_list = modules.module_list()
> +
> + for module in module_list:
> + module_name = module['name'].string()
> + module_pattern = ".*/{0}\.ko(?:.debug)?$".format(
> + module_name.replace("_", r"[_\-]"))
> + if re.match(module_pattern, mod_path) and os.path.exists(mod_path):
> + self.load_module_symbols(module, mod_path)
> + return
> + raise gdb.GdbError("%s is not a valid .ko\n" % mod_path)
> +
> def load_all_symbols(self):
> gdb.write("loading vmlinux\n")
>
> @@ -176,6 +190,11 @@ lx-symbols command."""
> self.module_files = []
> self.module_files_updated = False
>
> + argv = gdb.string_to_argv(arg)
> + if len(argv) == 1:
> + self.load_ko_symbols(argv[0])
> + return
But this obviously breaks it, since passing a single path will go into
the if, then complain "some/folder/ is not a valid .ko" and exit.
But I'm not even sure how you intended this to work _at all_, because in
the context before this if, we have:
self.module_paths = [os.path.abspath(os.path.expanduser(p))
for p in arg.split()]
self.module_paths.append(os.getcwd())
so you first add the (file!) to the list of paths, and then try to load
the file by finding modules in the paths, and filtering by the specified
file? That seems ... very roundabout, and can even only work if the file
can be found via os.getcwd(), so you could never specify an absolute
filename?
All that seems counter to what the patch was meant to do.
I suspect that really you need to individually check "is it a file or a
directory" before handling any of this, and if it's actually a file,
don't use it as a _filter_ as you do in load_ko_symbols() now but
directly use it as is with load_module_symbols()?
@Jan, can we revert this? I came up with the following trivial fix that
makes it at least not break the original use case of passing a single-
entry directory list, but it really doesn't seem right one way or the
other.
--- a/scripts/gdb/linux/symbols.py
+++ b/scripts/gdb/linux/symbols.py
@@ -191,7 +191,7 @@ lx-symbols command."""
self.module_files_updated = False
argv = gdb.string_to_argv(arg)
- if len(argv) == 1:
+ if len(argv) == 1 and os.path.isfile(argv[0]):
self.load_ko_symbols(argv[0])
return
johannes
next prev parent reply other threads:[~2023-09-12 9:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 8:30 [PATCH v2 0/8] Add GDB memory helper commands Kuan-Ying Lee
2023-08-08 8:30 ` [PATCH v2 1/8] scripts/gdb/symbols: add specific ko module load command Kuan-Ying Lee
2023-09-12 9:41 ` Johannes Berg [this message]
2023-09-12 16:23 ` Andrew Morton
2023-08-08 8:30 ` [PATCH v2 2/8] scripts/gdb/modules: add get module text support Kuan-Ying Lee
2023-08-08 8:30 ` [PATCH v2 3/8] scripts/gdb/utils: add common type usage Kuan-Ying Lee
2023-08-08 8:30 ` [PATCH v2 4/8] scripts/gdb/aarch64: add aarch64 page operation helper commands and configs Kuan-Ying Lee
2023-08-08 8:30 ` [PATCH v2 5/8] scripts/gdb/stackdepot: Add stackdepot support Kuan-Ying Lee
2023-08-08 8:30 ` [PATCH v2 6/8] scripts/gdb/page_owner: add page owner support Kuan-Ying Lee
2023-08-08 8:30 ` [PATCH v2 7/8] scripts/gdb/slab: Add slab support Kuan-Ying Lee
2023-08-08 8:30 ` [PATCH v2 8/8] scripts/gdb/vmalloc: add vmallocinfo support Kuan-Ying Lee
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=c44b748307a074d0c250002cdcfe209b8cce93c9.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Kuan-Ying.Lee@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=casper.li@mediatek.com \
--cc=chinwen.chang@mediatek.com \
--cc=jan.kiszka@siemens.com \
--cc=kbingham@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=qun-wei.lin@mediatek.com \
/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