Re: Python enabled gdb on Windows and relocation

[Ruben Van Boxem <vanboxem.ruben@gmail.com>]

2011/5/14 Doug Evans <dje@google.com>:
> 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 was cross-compiling a mingw toolchain+gdb from Linux, so I used
--with-python without a value (because gdb configure tries to find the
Python executabe), and I added -I"/path/to/python/includes" to CFLAGS
and -L"/path/to/pythondll/importlib" to LDFLAGS, which built as it
should. This is hacky though, and gdb configure should provide
--with-python-libs and --with-python-include to make it more
streamlined with any other build prerequisite (like
gmp/mpfr/mpc/cloog/ppl in GCC for example).

>
>> 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.]

That way would be almost ideal, but a hardcoded *relative* path to the
python scripts (that is standardized within gdb) wouldn't hurt. An
extra environment variable would require a lot of explaining for
Windows, and is not "plug-and-play", like the rest of a sysrooted
toolchain is supposed to be like. I think this should work on all
setups:

1. Check hardcoded path; my suggestion would be "<gdb
executable>/../lib/python27"
2. If this fails to find the necessary files/scripts, find it like you
described above in Linux, without PYTHONPATH set.
3. Check PYTHONPATH.

I would think only number one would change, and perhaps be only
enabled with a special configure option. Nothing else would have to
change, and Windows users would rejoice :)
Again, this is only my suggestion, if there are problems with it in
way I haven't thought of, please say so, and we can come up with
another solution.

>
>> 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.
>

Thanks for the prompt response.