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

scripts/gdb: fix debugging modules compiled with hot/cold partitioning

2019-12-05T14:34:10Z

[ Upstream commit 8731acc5068eb3f422a45c760d32198175c756f8 ] gcc's -freorder-blocks-and-partition option makes it group frequently and infrequently used code in .text.hot and .text.unlikely sections respectively. At least when building modules on s390, this option is used by default. gdb assumes that all code is located in .text section, and that .text section is located at module load address. With such modules this is no longer the case: there is code in .text.hot and .text.unlikely, and either of them might precede .text. Fix by explicitly telling gdb the addresses of code sections. It might be tempting to do this for all sections, not only the ones in the white list. Unfortunately, gdb appears to have an issue, when telling it about e.g. loadable .note.gnu.build-id section causes it to think that non-loadable .note.Linux section is loaded at address 0, which in turn causes NULL pointers to be resolved to bogus symbols. So keep using the white list approach for the time being. Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich Reviewed-by: Jan Kiszka Cc: Kieran Bingham Cc: Heiko Carstens Cc: Vasily Gorbik Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

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