From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17046 invoked by alias); 14 May 2011 18:31:19 -0000 Received: (qmail 17027 invoked by uid 22791); 14 May 2011 18:31:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 May 2011 18:30:57 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p4EIUukS009080 for ; Sat, 14 May 2011 11:30:56 -0700 Received: from yxs7 (yxs7.prod.google.com [10.190.5.135]) by wpaz21.hot.corp.google.com with ESMTP id p4EIUtlC017689 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 14 May 2011 11:30:55 -0700 Received: by yxs7 with SMTP id 7so1627532yxs.33 for ; Sat, 14 May 2011 11:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.33.1 with SMTP id l1mr2410011agj.207.1305397855072; Sat, 14 May 2011 11:30:55 -0700 (PDT) Received: by 10.90.72.6 with HTTP; Sat, 14 May 2011 11:30:55 -0700 (PDT) In-Reply-To: References: Date: Sat, 14 May 2011 18:31:00 -0000 Message-ID: Subject: Re: Python enabled gdb on Windows and relocation From: Doug Evans To: vanboxem.ruben@gmail.com Cc: gdb@sourceware.org, python-list@python.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-IsSubscribed: yes 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/msg00061.txt.bz2 On Sat, May 14, 2011 at 2:09 AM, Ruben Van Boxem wrote: > 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=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). Ah. Cross-compiling gdb with python is in need of improvement. Alas python hasn't been designed with cross-compilation in mind (e.g. build on linux, run on windows). AIUI, the way to get the parameters required for compiling with libpython is to get them from python's "distutils": kinda hard to do in a cross-compile. Done correctly there's no need to run python. I haven't done anything more to support python in gdb's configure.ac because it's not clear to me what the right thing to do is: distutils provides more than just --libs and --includes (btw, we don't use --libs though, we use --ldflags which includes all of: the directory in which to find libpython, the -l for libpython, and the -l's for all the other libraries python needs). [Which isn't to say that someone else isn't free to tackle this.] In the meantime, what I've been doing is a hack: write a script that responds to: --includes --ldflags --exec-prefix and pass that as --with-python. E.g. bash$ cat $HOME/my-python-for-config #! /bin/sh if [ $# -ne 2 ] then echo "Bad # args. Blech!" >&2 exit 1 fi # The first argument is the path to python-config.py, ignore it. case "$2" in --includes) echo "-I/usr/include/python2.6 -I/usr/include/python2.6" ;; --ldflags) echo "-L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm -lpython2.6" ;; --exec-prefix) echo "/usr" ;; *) echo "Bad arg $2. Blech!" >&2 ; exit 1 ;; esac exit 0 bash$ ./configure --with-python=$HOME/my-python-for-config [...] [...] Note that --exec-prefix is the runtime location of python. GCC uses this to tell libpython where to find its support files. [grep for Py_SetProgramName in gdb/python/python.c] >>> 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. See above re: --exec-prefix. > 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 " 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. The problem being solved by the proposed GDB_PYTHONPATH is "What if the user has PYTHONPATH set and it points to an incompatible version of python?". Leaving such a value for PYTHONPATH set while gdb's python is running feels wrong (and IIRC has caused some problems). The problem of telling python where to find itself is already solved (or at least is intended to be solved) with gdb's calling Py_SetProgramName with a value derived from the python-provided --exec-prefix. > 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.