From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6256 invoked by alias); 14 May 2011 09:09:31 -0000 Received: (qmail 6243 invoked by uid 22791); 14 May 2011 09:09:29 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qy0-f176.google.com (HELO mail-qy0-f176.google.com) (209.85.216.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 May 2011 09:09:14 +0000 Received: by qyk30 with SMTP id 30so2283148qyk.0 for ; Sat, 14 May 2011 02:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.130.155 with SMTP id t27mr1708431qcs.276.1305364153367; Sat, 14 May 2011 02:09:13 -0700 (PDT) Received: by 10.229.250.66 with HTTP; Sat, 14 May 2011 02:09:13 -0700 (PDT) Reply-To: vanboxem.ruben@gmail.com In-Reply-To: References: Date: Sat, 14 May 2011 09:09:00 -0000 Message-ID: Subject: Re: Python enabled gdb on Windows and relocation From: Ruben Van Boxem To: Doug Evans Cc: gdb@sourceware.org, python-list@python.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00058.txt.bz2 2011/5/14 Doug Evans : > On Thu, May 12, 2011 at 9:19 AM, Ruben Van Boxem > 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=3DSOME_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 "/../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): >> =C2=A0 File "", line 35, in >> =C2=A0 File "m:\development\mingw64\share\gdb/python/gdb/__init__.py", l= ine >> 18, in >> =C2=A0=C2=A0=C2=A0 gdb.command.pretty_printers.register_pretty_printer_c= ommands() >> =C2=A0 File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_= printers.py", >> line 368, in register_pretty_printer_commands >> =C2=A0=C2=A0=C2=A0 InfoPrettyPrinter() >> =C2=A0 File "m:\development\mingw64\share\gdb/python/gdb\command\pretty_= printers.py", >> line 100, in __init__ >> =C2=A0=C2=A0=C2=A0 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 e= xist. > I don't see how that can happen as python is initialized long after > the info command is created. > Thanks for the prompt response.