user/sven/linux.git/scripts/gdb/linux, branch v4.9.170

scripts/gdb/linux/tasks.py: fix get_thread_info

2018-01-23T18:57:08Z

commit 883d50f56d263f70fd73c0d96b09eb36c34e9305 upstream. Since kernel 4.9, the thread_info has been moved into task_struct, no longer locates at the bottom of kernel stack. See commits c65eacbe290b ("sched/core: Allow putting thread_info into task_struct") and 15f4eae70d36 ("x86: Move thread_info into task_struct"). Before fix: (gdb) set $current = $lx_current() (gdb) p $lx_thread_info($current) $1 = {flags = 1470918301} (gdb) p $current.thread_info $2 = {flags = 2147483648} After fix: (gdb) p $lx_thread_info($current) $1 = {flags = 2147483648} (gdb) p $current.thread_info $2 = {flags = 2147483648} Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct") Signed-off-by: Xi Kangjie Acked-by: Jan Kiszka Acked-by: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Revert "scripts/gdb: add a Radix Tree Parser"

2016-07-15T05:54:27Z

This reverts commit e127a73d41ac ("scripts/gdb: add a Radix Tree Parser") The python implementation of radix-tree was merged at the same time as the radix-tree system was heavily reworked from commit e9256efcc8e3 ("radix-tree: introduce radix_tree_empty") to 3bcadd6fa6c4 ("radix-tree: free up the bottom bit of exceptional entries for reuse") and no longer functions, but also prevents other gdb scripts from loading. This functionality has not yet hit a release, so simply remove it for now Link: http://lkml.kernel.org/r/1467127337-11135-6-git-send-email-kieran@bingham.xyz Signed-off-by: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: Perform path expansion to lx-symbol's arguments

2016-07-15T05:54:27Z

Python doesn't do automatic expansion of paths. In case one passes path of the from ~/foo/bar the gdb scripts won't automatically expand that and as a result the symbols files won't be loaded. Fix this by explicitly expanding all paths which begin with "~" Link: http://lkml.kernel.org/r/1467127337-11135-5-git-send-email-kieran@bingham.xyz Signed-off-by: Nikolay Borisov Signed-off-by: Kieran Bingham Reviewed-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: add constants.py to .gitignore

2016-07-15T05:54:27Z

Since scripts/gdb/linux/constants.py is autogenerated, this should have been added to .gitignore when it was introduced. Fixes: f197d75fcad1 ("scripts/gdb: provide linux constants") Link: http://lkml.kernel.org/r/1467127337-11135-4-git-send-email-kieran@bingham.xyz Signed-off-by: Omar Sandoval Signed-off-by: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: rebuild constants.py on dependancy change

2016-07-15T05:54:27Z

The autogenerated constants.py file was only being built on the initial call, and if the constants.py.in file changed. As we are utilising the CPP hooks, we can successfully use the call if_changed_dep rules to determine when to rebuild the file based on it's inclusions. Link: http://lkml.kernel.org/r/1467127337-11135-3-git-send-email-kieran@bingham.xyz Signed-off-by: Kieran Bingham Reported-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: silence 'nothing to do' message

2016-07-15T05:54:27Z

The constants.py generation, involves a rule to link into the main makefile. This rule has no command and generates a spurious warning message in the build logs when CONFIG_SCRIPTS_GDB is enabled. Fix simply by giving a no-op action Link: http://lkml.kernel.org/r/1467127337-11135-2-git-send-email-kieran@bingham.xyz Signed-off-by: Kieran Bingham Reported-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: decode bytestream on dmesg for Python3

2016-05-24T00:04:14Z

The recent fixes to lx-dmesg, now allow the command to print successfully on Python3, however the python interpreter wraps the bytes for each line with a b'' marker. To remove this, we need to decode the line, where .decode() will default to 'UTF-8' Link: http://lkml.kernel.org/r/d67ccf93f2479c94cb3399262b9b796e0dbefcf2.1462865983.git.jan.kiszka@siemens.com Signed-off-by: Kieran Bingham Acked-by: Dom Cote Tested-by: Dom Cote Signed-off-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: fix issue with dmesg.py and python 3.X

2016-05-24T00:04:14Z

When built against Python 3, GDB differs in the return type for its read_memory function, causing the lx-dmesg command to fail. Now that we have an improved read_16() we can use the new read_memoryview() abstraction to make lx-dmesg return valid data on both current Python APIs Tested with python 3.4 and 2.7 Tested with gdb 7.7 Link: http://lkml.kernel.org/r/28477b727ff7fe3101fd4e426060e8a68317a639.1462865983.git.jan.kiszka@siemens.com Signed-off-by: Dom Cote [kieran@bingham.xyz: Adjusted commit log to better reflect code changes] Tested-by: Kieran Bingham (Py2.7,Py3.4,GDB10) Signed-off-by: Kieran Bingham Signed-off-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: improve types abstraction for gdb python scripts

2016-05-24T00:04:14Z

Change the read_u16 function so it accepts both 'str' and 'byte' as type for the arguments. When calling read_memory() from gdb API, depending on if it was built with 2.7 or 3.X, the format used to return the data will differ ( 'str' for 2.7, and 'byte' for 3.X ). Add a function read_memoryview() to be able to get a 'memoryview' object back from read_memory() both with python 2.7 and 3.X . Tested with python 3.4 and 2.7 Tested with gdb 7.7 Link: http://lkml.kernel.org/r/73621f564503137a002a639d174e4fb35f73f462.1462865983.git.jan.kiszka@siemens.com Signed-off-by: Dom Cote Tested-by: Kieran Bingham (Py2.7,Py3.4,GDB10) Signed-off-by: Kieran Bingham Signed-off-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: add lx_thread_info_by_pid helper

2016-05-24T00:04:14Z

The tasks module already provides helpers to find the task struct by pid, and the thread_info by task struct; however this is cumbersome to utilise on the gdb commandline. Wrap these two functionalities together in an extra single helper to allow exploring the thread info, from a PID value Link: http://lkml.kernel.org/r/dadc5667f053ec811eb3e3033d99d937fedbc93b.1462865983.git.jan.kiszka@siemens.com Signed-off-by: Kieran Bingham Signed-off-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds