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

Groups > comp.lang.python > #5339 > unrolled thread

Re: Python enabled gdb on Windows and relocation

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python enabled gdb on Windows and relocation Doug Evans <dje@google.com> - 2011-05-13 23:38 -0700

#5339 — Re: Python enabled gdb on Windows and relocation

On Thu, May 12, 2011 at 9:19 AM, Ruben Van Boxem
<vanboxem.ruben@gmail.com> wrote:
> (now in plain-text as required by gdb mailing list)
>
> Hi,
>
> I am currently trying to integrate Python support into my toolchain
> build (including GDB of course). It is a sysrooted
> binutils+GCC+GDB+mingw-w64 toolchain.
>
> I currently have the basic setup working: I can link gdb with my
> manually generated import lib to the python dll from the official
> Windows install. If there is anything I am missing or a very easy
> solution to the problems decsribed below, please just say so. I am
> only suggesting what I would like to happen.
>
> Now on to the problems I'd like to discuss:
>
> 1. gdb.exe won't start without me having set PYTHONPATH manually.

In a properly configured/built gdb on linux this isn't necessary, even
if python is installed in some random place.
I'm not sure about windows though.
Did you specify --with-python when you configured gdb, and if so did
you specify a value?
e.g., --with-python=SOME_VALUE

> I understand the need for this, but as gdb requires Python 2, and users
> of my toolchain may have installed Python 3 or a 32-bit version python
> they want to use from the same environment (without changing their own
> PYTHONPATH), there is no way to run python-enabled gdb.
> [...]

Yeah.
There is a proposal to add GDB_PYTHONPATH (or some such IIRC) and have
gdb use that instead of PYTHONPATH if it exists, but there's been
resistance to it.
I think(!) what would happen is that gdb would set $PYTHONPATH to the
value of $GDB_PYTHONPATH.
[Inferiors started by gdb should still get the original value of
PYTHONPATH though.]

> 2. With PYTHONPATH set as a temporary workaround, gdb starts, but
> spits out a traceback:
> Traceback (most recent call last):
>   File "<string>", line 35, in <module>
>   File "m:\development\mingw64\share\gdb/python/gdb/__init__.py", line
> 18, in <module>
>     gdb.command.pretty_printers.register_pretty_printer_commands()
>   File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py",
> line 368, in register_pretty_printer_commands
>     InfoPrettyPrinter()
>   File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_printers.py",
> line 100, in __init__
>     gdb.COMMAND_DATA)
> RuntimeError: Could not find command prefix info.
>
> This is a minor problem I think, as "python import time" "python print
> time.clock()" works as expected. What is wrong?

I'm not sure.
The error message is complaining that the "info" command prefix doesn't exist.
I don't see how that can happen as python is initialized long after
the info command is created.

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web