Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1313137 > unrolled thread

[RFC PATCH 0/5] scripts/gdb: Linux awareness debug commands

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/5] scripts/gdb: Linux awareness debug commands Kieran Bingham <kieran.bingham@linaro.org> - 2016-01-20 12:20 +0100
    [PATCH 1/5] scripts/gdb: Provide linux constants Kieran Bingham <kieran.bingham@linaro.org> - 2016-01-20 12:20 +0100
      Re: [PATCH 1/5] scripts/gdb: Provide linux constants Jan Kiszka <jan.kiszka@siemens.com> - 2016-01-23 16:10 +0100
        Re: [PATCH 1/5] scripts/gdb: Provide linux constants Kieran Bingham <kieran.bingham@linaro.org> - 2016-01-24 01:20 +0100

#1313137 — [RFC PATCH 0/5] scripts/gdb: Linux awareness debug commands

Hi Jan,

Following on from the initial commands provided earlier, I wanted to send an
early set of patches for review, feedback and iteration.

There is an /proc/interrupts command on the way too but that will be later,
and I wanted to get these started.

Particular commentry is either in the comments area of the patch, or in the
code itself.

A particular coding-style question is on the docstrings. Most of the existing
commands do not indent their multiline docstrings. Is this preferred?

And also, what is your take on line-length.
Should it be hard and fast always < 79, or OK > if it keeps things readable?:

pep8 proc.py
proc.py:321:80: E501 line too long (80 > 79 characters)
proc.py:363:80: E501 line too long (80 > 79 characters)
proc.py:365:80: E501 line too long (82 > 79 characters)
proc.py:378:80: E501 line too long (80 > 79 characters)

These 4 lines come from [PATCH 5/5] scripts/gdb: Add meminfo command
If I move the helper class functions out to file scope, that could trim
the 'self.' keyword, and make the lines a little shorter ...

Anyway, I look forward to hearing your comments, and any input from any other
interested parties too!

If anyone has any ideas for commands that they would like to see available,
or useful kernel parsers, now is a great time to get involved!


Regards
--
Kieran

Kieran Bingham (5):
  scripts/gdb: Provide linux constants
  scripts/gdb: Provide a kernel list item generator
  scripts/gdb: Add io resource readers
  scripts/gdb: Add mount point list command
  scripts/gdb: Add meminfo command

 scripts/gdb/linux/Makefile        |   9 +-
 scripts/gdb/linux/constants.py.in |  65 ++++++++
 scripts/gdb/linux/lists.py        |   9 +
 scripts/gdb/linux/proc.py         | 340 ++++++++++++++++++++++++++++++++++++++
 scripts/gdb/vmlinux-gdb.py        |   1 +
 5 files changed, 422 insertions(+), 2 deletions(-)
 create mode 100644 scripts/gdb/linux/constants.py.in

-- 
2.5.0

[toc] | [next] | [standalone]

#1313140 — [PATCH 1/5] scripts/gdb: Provide linux constants

Some macro's and defines are needed when parsing memory, and without
compiling the kernel as -g3 they are not available in the debug-symbols.

We use the pre-processor here to extract constants to a dedicated module
for the linux debugger extensions

Signed-off-by: Kieran Bingham <kieran.bingham@linaro.org>
---

I've added a 'constants.py' which is automatically generated. This allows
values not available to the debugger, through #defines to be provided to
our scripts.

The alternative method for this is to create a c-object file to obtain values
through symbols instead, and compile segments with -g3 to include macro
definitions in the debug-info.

I'd appreciate your thoughts on these options.

 scripts/gdb/linux/Makefile        |  9 +++++++--
 scripts/gdb/linux/constants.py.in | 22 ++++++++++++++++++++++
 scripts/gdb/vmlinux-gdb.py        |  1 +
 3 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 scripts/gdb/linux/constants.py.in

diff --git a/scripts/gdb/linux/Makefile b/scripts/gdb/linux/Makefile
index 6cf1ecf61057..50864f408ca8 100644
--- a/scripts/gdb/linux/Makefile
+++ b/scripts/gdb/linux/Makefile
@@ -2,10 +2,15 @@ always := gdb-scripts
 
 SRCTREE := $(shell cd $(srctree) && /bin/pwd)
 
-$(obj)/gdb-scripts:
+$(obj)/gdb-scripts: $(obj)/constants.py
 ifneq ($(KBUILD_SRC),)
 	$(Q)ln -fsn $(SRCTREE)/$(obj)/*.py $(objtree)/$(obj)
 endif
 	@:
 
-clean-files := *.pyc *.pyo $(if $(KBUILD_SRC),*.py)
+$(obj)/constants.py: $(SRCTREE)/$(obj)/constants.py.in
+	@echo "  GDB PP  $@"
+	@$(CPP) -E -x c -P $(c_flags) $< > $@
+	@sed -i '1,/<!-- end-c-headers -->/d;' $@
+
+clean-files := *.pyc *.pyo $(if $(KBUILD_SRC),*.py) $(obj)/constants.py
diff --git a/scripts/gdb/linux/constants.py.in b/scripts/gdb/linux/constants.py.in
new file mode 100644
index 000000000000..d84084ac945b
--- /dev/null
+++ b/scripts/gdb/linux/constants.py.in
@@ -0,0 +1,22 @@
+/*
+ * gdb helper commands and functions for Linux kernel debugging
+ *
+ *  Kernel constants derived from include files.
+ *
+ * Copyright (c) 2016 Linaro Ltd
+ *
+ * Authors:
+ *  Kieran Bingham <kieran.bingham@linaro.org>
+ *
+ * This work is licensed under the terms of the GNU GPL version 2.
+ *
+ */
+
+/* We need to stringify expanded macros so that they can be parsed */
+#define STRING(x) #x
+#define XSTRING(x) STRING(x)
+
+/* The build system will take care of deleting everything above this marker */
+<!-- end-c-headers -->
+
+import gdb
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index d5943eca19cd..6e0b0afd888a 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -30,3 +30,4 @@ else:
     import linux.cpus
     import linux.lists
     import linux.proc
+    import linux.constants
-- 
2.5.0

[toc] | [prev] | [next] | [standalone]

#1315652 — Re: [PATCH 1/5] scripts/gdb: Provide linux constants

On 2016-01-20 12:15, Kieran Bingham wrote:
> Some macro's and defines are needed when parsing memory, and without
> compiling the kernel as -g3 they are not available in the debug-symbols.
> 
> We use the pre-processor here to extract constants to a dedicated module
> for the linux debugger extensions
> 
> Signed-off-by: Kieran Bingham <kieran.bingham@linaro.org>
> ---
> 
> I've added a 'constants.py' which is automatically generated. This allows
> values not available to the debugger, through #defines to be provided to
> our scripts.
> 
> The alternative method for this is to create a c-object file to obtain values
> through symbols instead, and compile segments with -g3 to include macro
> definitions in the debug-info.
> 
> I'd appreciate your thoughts on these options.

I cannot assess your second proposal. How invasive will it be? Is it
promising to reduce the maintenance? What will be the impact of -g3?

This approach seems pragmatic and sufficient. Would be fine with me
unless the other has significant advantages.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[toc] | [prev] | [next] | [standalone]

#1315790 — Re: [PATCH 1/5] scripts/gdb: Provide linux constants

On 23/01/16 15:05, Jan Kiszka wrote:
> On 2016-01-20 12:15, Kieran Bingham wrote:
>> Some macro's and defines are needed when parsing memory, and without
>> compiling the kernel as -g3 they are not available in the debug-symbols.
>>
>> We use the pre-processor here to extract constants to a dedicated module
>> for the linux debugger extensions
>>
>> Signed-off-by: Kieran Bingham <kieran.bingham@linaro.org>
>> ---
>>
>> I've added a 'constants.py' which is automatically generated. This allows
>> values not available to the debugger, through #defines to be provided to
>> our scripts.
>>
>> The alternative method for this is to create a c-object file to obtain values
>> through symbols instead, and compile segments with -g3 to include macro
>> definitions in the debug-info.
>>
>> I'd appreciate your thoughts on these options.
> 
> I cannot assess your second proposal. How invasive will it be? Is it
> promising to reduce the maintenance? What will be the impact of -g3?
> 
> This approach seems pragmatic and sufficient. Would be fine with me
> unless the other has significant advantages.

At the moment, I believe the current method (generating a constants.py)
is my preferred method. It's less intrusive, and can be generated for a
kernel which is to be debugged, which perhaps didn't have GDB_SCRIPTS
enabled at the time.

A c-object file would be more limiting I believe.

Kieran

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web