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.comSigned-off-by: NDom Cote <buzdelabuz2+git@gmail.com>
[kieran@bingham.xyz: Adjusted commit log to better reflect code changes]
Tested-by: Kieran Bingham <kieran@bingham.xyz> (Py2.7,Py3.4,GDB10)
Signed-off-by: NKieran Bingham <kieran@bingham.xyz>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NThiébaud Weksteen <thiebaud@weksteen.fr>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I tried to use these scripts in an ubuntu 14.04 host (gdb 7.7 compiled
against python 3.3) but there were several errors.

I believe this patch fixes these issues so that the commands now work (I
tested lx-symbols, lx-dmesg, lx-lsmod).

Main issues that needed to be resolved:

  * In python 2 iterators have a "next()" method. In python 3 it is
    __next__() instead (so let's just add both).

  * In older python versions there was an implicit conversion
    in object.__format__() (used when an object is in string.format())
    where it was converting the object to str first and then
    calling str's __format__(). This has now been removed so
    we must explicitly convert to str the objects for which
    we need to keep this behavior.

  * In dmesg.py: in python 3 log_buf is now a "memoryview" object
    which needs to be converted to a string in order to use string
    methods like "splitlines()". Luckily memoryview exists in
    python 2.7.6 as well, so we can convert log_buf to memoryview
    and use the same code in both python 2 and python 3.

This version of the patch has now been tested with gdb 7.7 and both python
3.4 and python 2.7.6 (I think asking for at least python 2.7.6 is a
reasonable requirement instead of complicating the code with version
checks etc).
Signed-off-by: NPantelis Koukousoulas <pktoss@gmail.com>
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This pokes into the log buffer of the debugged kernel, dumping it to the
gdb console.  Helping in case the target should or can no longer execute
dmesg itself.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>