| Message ID | 87egmighkn.fsf@blackfin.pond.sub.org |
|---|---|
| State | New |
| Headers | show |
On 2015-05-15 14:18, Markus Armbruster wrote: > Peter Maydell <peter.maydell@linaro.org> writes: > >> On 15 May 2015 at 08:58, Markus Armbruster <armbru@redhat.com> wrote: >>> Since you're touching qemu-gdb.py anyway, could you stick in a brief >>> comment explaining how to put it to use? >> >> Good idea. It turns out the answer is just "source it from gdb", >> but it took me a little while to find that out, so worth commenting. >> I also have a patch which makes it do the 'ignore SIGUSR1' bit >> by doing 'handle SIGUSR1 pass noprint nostop' for you. > > Here's how to load scripts/qemu-gdb.py automatically: > > * Apply the appended patch to turn it into a gdb init file > > That's what it is, after all. It's not a standalone Python program. > > * Tell gdb to trust it > > Add a line like > > add-auto-load-safe-path ~/work/qemu/scripts/qemu-gdb.py > > to your ~/.gdbinit > > * Link it into the directory where you run gdb --args qemu... > > * Verify it works: > > $ gdb > [...] > (gdb) help qemu > Prefix for QEMU debug support commands > > List of qemu subcommands: > > qemu coroutine -- Display coroutine backtrace > qemu mtree -- Display the memory tree hierarchy > > Type "help qemu" followed by qemu subcommand name for full documentation. > Type "apropos word" to search for commands related to "word". > Command name abbreviations are allowed if unambiguous. > (gdb) > > If you know a better way to do this, please post it. > Yep, that's the basic idea behind gdb python scripts: myapp-gdb.py gets auto-pulled on "gdb myapp". Since some gdb 7.x, we have that security feature above which prevents pulling from arbitrary sources. > > diff --git a/scripts/qemu-gdb.py b/scripts/qemu-gdb.py > index 6c7f4fb..ac3087c 100644 > --- a/scripts/qemu-gdb.py > +++ b/scripts/qemu-gdb.py > @@ -1,5 +1,3 @@ > -#!/usr/bin/python > - > # GDB debugging support > # > # Copyright 2012 Red Hat, Inc. and/or its affiliates > @@ -13,7 +11,7 @@ > # Contributions after 2012-01-13 are licensed under the terms of the > # GNU GPL, version 2 or (at your option) any later version. > > - > +python What is this line doing? > import gdb > > def isnull(ptr): > > See also linux-4.x/scripts/gdb and linux-4.x/Documentation/gdb-kernel-debugging.txt for more references. For the kernel, we set the link during the build. Given the many aliases for qemu and the fact that quite a few developers run from the build directory, I guess that would make sense here as well. Helper functions are another interesting facility to consider. Trivial example: the kernel has $container_of(PTR, "TYPE", "ELEMENT"). Jan
Jan Kiszka <jan.kiszka@siemens.com> writes: > On 2015-05-15 14:18, Markus Armbruster wrote: >> Peter Maydell <peter.maydell@linaro.org> writes: >> >>> On 15 May 2015 at 08:58, Markus Armbruster <armbru@redhat.com> wrote: >>>> Since you're touching qemu-gdb.py anyway, could you stick in a brief >>>> comment explaining how to put it to use? >>> >>> Good idea. It turns out the answer is just "source it from gdb", >>> but it took me a little while to find that out, so worth commenting. >>> I also have a patch which makes it do the 'ignore SIGUSR1' bit >>> by doing 'handle SIGUSR1 pass noprint nostop' for you. >> >> Here's how to load scripts/qemu-gdb.py automatically: >> >> * Apply the appended patch to turn it into a gdb init file >> >> That's what it is, after all. It's not a standalone Python program. >> >> * Tell gdb to trust it >> >> Add a line like >> >> add-auto-load-safe-path ~/work/qemu/scripts/qemu-gdb.py >> >> to your ~/.gdbinit >> >> * Link it into the directory where you run gdb --args qemu... >> >> * Verify it works: >> >> $ gdb >> [...] >> (gdb) help qemu >> Prefix for QEMU debug support commands >> >> List of qemu subcommands: >> >> qemu coroutine -- Display coroutine backtrace >> qemu mtree -- Display the memory tree hierarchy >> >> Type "help qemu" followed by qemu subcommand name for full documentation. >> Type "apropos word" to search for commands related to "word". >> Command name abbreviations are allowed if unambiguous. >> (gdb) >> >> If you know a better way to do this, please post it. >> > > Yep, that's the basic idea behind gdb python scripts: myapp-gdb.py gets > auto-pulled on "gdb myapp". Since some gdb 7.x, we have that security > feature above which prevents pulling from arbitrary sources. > >> >> diff --git a/scripts/qemu-gdb.py b/scripts/qemu-gdb.py >> index 6c7f4fb..ac3087c 100644 >> --- a/scripts/qemu-gdb.py >> +++ b/scripts/qemu-gdb.py >> @@ -1,5 +1,3 @@ >> -#!/usr/bin/python >> - >> # GDB debugging support >> # >> # Copyright 2012 Red Hat, Inc. and/or its affiliates >> @@ -13,7 +11,7 @@ >> # Contributions after 2012-01-13 are licensed under the terms of the >> # GNU GPL, version 2 or (at your option) any later version. >> >> - >> +python > > What is this line doing? Found here: https://stackoverflow.com/questions/16553283/python-code-in-gdb-init-file-gdbinit It doesn't work for me without it. >> import gdb >> >> def isnull(ptr): >> >> > > See also linux-4.x/scripts/gdb and > linux-4.x/Documentation/gdb-kernel-debugging.txt for more references. > > For the kernel, we set the link during the build. Given the many aliases > for qemu and the fact that quite a few developers run from the build > directory, I guess that would make sense here as well. > > Helper functions are another interesting facility to consider. Trivial > example: the kernel has $container_of(PTR, "TYPE", "ELEMENT"). Neat!
On 2015-05-15 15:21, Markus Armbruster wrote: > Jan Kiszka <jan.kiszka@siemens.com> writes: > >> On 2015-05-15 14:18, Markus Armbruster wrote: >>> Peter Maydell <peter.maydell@linaro.org> writes: >>> >>>> On 15 May 2015 at 08:58, Markus Armbruster <armbru@redhat.com> wrote: >>>>> Since you're touching qemu-gdb.py anyway, could you stick in a brief >>>>> comment explaining how to put it to use? >>>> >>>> Good idea. It turns out the answer is just "source it from gdb", >>>> but it took me a little while to find that out, so worth commenting. >>>> I also have a patch which makes it do the 'ignore SIGUSR1' bit >>>> by doing 'handle SIGUSR1 pass noprint nostop' for you. >>> >>> Here's how to load scripts/qemu-gdb.py automatically: >>> >>> * Apply the appended patch to turn it into a gdb init file >>> >>> That's what it is, after all. It's not a standalone Python program. >>> >>> * Tell gdb to trust it >>> >>> Add a line like >>> >>> add-auto-load-safe-path ~/work/qemu/scripts/qemu-gdb.py >>> >>> to your ~/.gdbinit >>> >>> * Link it into the directory where you run gdb --args qemu... >>> >>> * Verify it works: >>> >>> $ gdb >>> [...] >>> (gdb) help qemu >>> Prefix for QEMU debug support commands >>> >>> List of qemu subcommands: >>> >>> qemu coroutine -- Display coroutine backtrace >>> qemu mtree -- Display the memory tree hierarchy >>> >>> Type "help qemu" followed by qemu subcommand name for full documentation. >>> Type "apropos word" to search for commands related to "word". >>> Command name abbreviations are allowed if unambiguous. >>> (gdb) >>> >>> If you know a better way to do this, please post it. >>> >> >> Yep, that's the basic idea behind gdb python scripts: myapp-gdb.py gets >> auto-pulled on "gdb myapp". Since some gdb 7.x, we have that security >> feature above which prevents pulling from arbitrary sources. >> >>> >>> diff --git a/scripts/qemu-gdb.py b/scripts/qemu-gdb.py >>> index 6c7f4fb..ac3087c 100644 >>> --- a/scripts/qemu-gdb.py >>> +++ b/scripts/qemu-gdb.py >>> @@ -1,5 +1,3 @@ >>> -#!/usr/bin/python >>> - >>> # GDB debugging support >>> # >>> # Copyright 2012 Red Hat, Inc. and/or its affiliates >>> @@ -13,7 +11,7 @@ >>> # Contributions after 2012-01-13 are licensed under the terms of the >>> # GNU GPL, version 2 or (at your option) any later version. >>> >>> - >>> +python >> >> What is this line doing? > > Found here: > https://stackoverflow.com/questions/16553283/python-code-in-gdb-init-file-gdbinit The author there puts his code into .gdbinit, which is a gdb script, not a python one. > > It doesn't work for me without it. When sourcing? Works fine here (gdb 7.7.something). In any case, when you pull in the script via auto-load, that extra non-python statement will break. Try "python python". ;) Jan
Jan Kiszka <jan.kiszka@siemens.com> writes: > On 2015-05-15 15:21, Markus Armbruster wrote: >> Jan Kiszka <jan.kiszka@siemens.com> writes: >> >>> On 2015-05-15 14:18, Markus Armbruster wrote: >>>> Peter Maydell <peter.maydell@linaro.org> writes: >>>> >>>>> On 15 May 2015 at 08:58, Markus Armbruster <armbru@redhat.com> wrote: >>>>>> Since you're touching qemu-gdb.py anyway, could you stick in a brief >>>>>> comment explaining how to put it to use? >>>>> >>>>> Good idea. It turns out the answer is just "source it from gdb", >>>>> but it took me a little while to find that out, so worth commenting. >>>>> I also have a patch which makes it do the 'ignore SIGUSR1' bit >>>>> by doing 'handle SIGUSR1 pass noprint nostop' for you. >>>> >>>> Here's how to load scripts/qemu-gdb.py automatically: >>>> >>>> * Apply the appended patch to turn it into a gdb init file >>>> >>>> That's what it is, after all. It's not a standalone Python program. >>>> >>>> * Tell gdb to trust it >>>> >>>> Add a line like >>>> >>>> add-auto-load-safe-path ~/work/qemu/scripts/qemu-gdb.py >>>> >>>> to your ~/.gdbinit >>>> >>>> * Link it into the directory where you run gdb --args qemu... Left out the important part: name the link .gdbinit ! >>>> * Verify it works: >>>> >>>> $ gdb >>>> [...] >>>> (gdb) help qemu >>>> Prefix for QEMU debug support commands >>>> >>>> List of qemu subcommands: >>>> >>>> qemu coroutine -- Display coroutine backtrace >>>> qemu mtree -- Display the memory tree hierarchy >>>> >>>> Type "help qemu" followed by qemu subcommand name for full documentation. >>>> Type "apropos word" to search for commands related to "word". >>>> Command name abbreviations are allowed if unambiguous. >>>> (gdb) >>>> >>>> If you know a better way to do this, please post it. >>>> >>> >>> Yep, that's the basic idea behind gdb python scripts: myapp-gdb.py gets >>> auto-pulled on "gdb myapp". Since some gdb 7.x, we have that security >>> feature above which prevents pulling from arbitrary sources. >>> >>>> >>>> diff --git a/scripts/qemu-gdb.py b/scripts/qemu-gdb.py >>>> index 6c7f4fb..ac3087c 100644 >>>> --- a/scripts/qemu-gdb.py >>>> +++ b/scripts/qemu-gdb.py >>>> @@ -1,5 +1,3 @@ >>>> -#!/usr/bin/python >>>> - >>>> # GDB debugging support >>>> # >>>> # Copyright 2012 Red Hat, Inc. and/or its affiliates >>>> @@ -13,7 +11,7 @@ >>>> # Contributions after 2012-01-13 are licensed under the terms of the >>>> # GNU GPL, version 2 or (at your option) any later version. >>>> >>>> - >>>> +python >>> >>> What is this line doing? >> >> Found here: >> https://stackoverflow.com/questions/16553283/python-code-in-gdb-init-file-gdbinit > > The author there puts his code into .gdbinit, which is a gdb script, not > a python one. That's exactly what I did in my experiments. >> >> It doesn't work for me without it. > > When sourcing? Works fine here (gdb 7.7.something). Nope, when auto-loading as .gdbinit from the current directory. > In any case, when you pull in the script via auto-load, that extra > non-python statement will break. Try "python python". ;) I know nothing about this kind of auto-load. I just read gdb-kernel-debugging.txt, and still know nothing :) Digging around in "info gdb"... aha, there's a section on "Python Auto-loading". Hmm... "set debug auto-load on"... Try linking it into the build tree, like this: $ cd bld/x86_64-softmmu/ $ ln -s ../../scripts/qemu-gdb.py qemu-system-x86_64-gdb.py Works. Could you post a patch so that make creates such links automatically?
diff --git a/scripts/qemu-gdb.py b/scripts/qemu-gdb.py index 6c7f4fb..ac3087c 100644 --- a/scripts/qemu-gdb.py +++ b/scripts/qemu-gdb.py @@ -1,5 +1,3 @@ -#!/usr/bin/python - # GDB debugging support # # Copyright 2012 Red Hat, Inc. and/or its affiliates @@ -13,7 +11,7 @@ # Contributions after 2012-01-13 are licensed under the terms of the # GNU GPL, version 2 or (at your option) any later version. - +python import gdb def isnull(ptr):