From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25912 invoked by alias); 19 Jul 2008 19:50:31 -0000 Received: (qmail 25903 invoked by uid 22791); 19 Jul 2008 19:50:30 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 Jul 2008 19:50:06 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1KKIRO-0004Gg-9z for gdb-patches@sources.redhat.com; Sat, 19 Jul 2008 19:50:02 +0000 Received: from 201.82.124.180 ([201.82.124.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Jul 2008 19:50:02 +0000 Received: from bauerman by 201.82.124.180 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Jul 2008 19:50:02 +0000 To: gdb-patches@sources.redhat.com From: Thiago Jung Bauermann Subject: Re: [RFA] iRe: [RFC][patch 1/9] initial Python support Date: Sat, 19 Jul 2008 19:50:00 -0000 Message-ID: References: <20080429155212.444237503@br.ibm.com> <20080429155304.288626880@br.ibm.com> <20080528205921.GA2969@caradoc.them.org> <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00376.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Jul 16, 2008 at 07:00:20PM -0300, Thiago Jung Bauermann wrote: >> +# >> +# python sub directory definitons >> +# >> +SUBDIR_PYTHON_OBS = \ >> + python-utils.o >> +SUBDIR_PYTHON_SRCS = \ >> + python/python.c \ >> + python/utils.c > > Can we call it python-utils.c or something else, instead? IMO having > different naming for the source file and object is very confusing. Actually I prefer to keep it this way. I am following the existing convention used to build other GDB components which live in their own subdirectories (cli/, mi/ and tui/). Since by the end of this patch series there will be 13 Python-related .c and .h files, I prefer to put them in their own subdirectory. IMHO having a flat source tree, with all source files lumped together, is more confusing than an object file named differently (but not much) than its source file. >> @@ -1283,7 +1303,11 @@ test-cp-name-parser$(EXEEXT): >> test-cp-name-parser.o $(LIBIBERTY) >> # duplicates. Files in the gdb/ directory can end up appearing in >> # COMMON_OBS (as a .o file) and CONFIG_SRCS (as a .c file). >> >> -INIT_FILES = $(COMMON_OBS) $(TSOBS) $(CONFIG_SRCS) >> +# NOTE: bauermann/2008-06-15: python.c needs to be explicitly included >> +# because the generation of init.c does not work for .c files which >> +# result in differently named objects (i.e., python/python -> python.o). >> + >> +INIT_FILES = $(COMMON_OBS) $(TSOBS) $(CONFIG_SRCS) python/python.c > > This comment doesn't make sense. python/python.c is already included > in INIT_FILES, because of CONFIG_SRCS. Indeed. I just tried saving face by reproducing the problem which prompted me to add python/python.c there in the first place, but couldn't. I don't remember why I needed it at the time. >> +# Flags needed to compile Python code (taken from python-config >> --cflags) +PYTHON_CFLAGS=-fno-strict-aliasing -DNDEBUG -fwrapv > > The output of python-config will vary by platform (that's the point of > having a helper program). So, I'm afraid we have to run python-config > if we need the cflags. Or else we could add these flags > unconditionally, if they work with the current compiler. Consider > non-GCC. I looked into using python-config, and found a problem: the CFLAGS it provides is just a copy of all the CFLAGS used when building the Python interpreter itself, including options which would make the python-related objects be compiled differently from the rest of GDB. For instance, in my system it includes -O2 (what if want to compile GDB with -O0?). In another system it also includes -fPIC. There's an open python ticket about this: http://bugs.python.org/issue3290 So I don't know yet how to solve the problem. :-/ Even if they fix it upstream, we want to support the broken systems out there. Perhaps get the python-config output and filter out options from a blacklist? >> + /* Create a couple objects which are used for Python's stdout and >> + stderr. */ >> + PyRun_SimpleString ("\ >> +import sys\n\ >> +class GdbOutputFile:\n\ >> + def close(self):\n\ >> + # Do nothing.\n\ >> + return None\n\ >> +\n\ >> + def isatty(self):\n\ >> + return False\n\ >> +\n\ >> + def write(self, s):\n\ >> + gdb.write(s)\n\ >> +\n\ >> + def writelines(self, iterable):\n\ >> + for line in iterable:\n\ >> + self.write(line)\n\ >> +\n\ >> + def flush(self):\n\ >> + gdb.flush()\n\ >> +\n\ >> +sys.stderr = GdbOutputFile()\n\ >> +sys.stdout = GdbOutputFile()\n\ > > This is OK for now, but it is likely to grow. There's code to convert > a text file into a C string, in features/ (used for XML files); maybe > we should internalize a couple of Python source files that way? I like the idea, will play with it... > Anyway, that's a future note, not a current problem. ... and provide a separate patch later. >> +/* Initialize dummy Python code. */ >> + >> +void >> +_initialize_python (void) >> +{ >> + add_com ("python", class_obscure, python_command, _("\ >> +Evaluate a Python command.\n\ >> +\n\ >> +Python scripting is not supported in this copy of GDB.\n\ >> +This command is only a placeholder.")); >> + >> + add_setshow_boolean_cmd ("python-stack", class_maintenance, >> + &gdbpy_should_print_stack, _("\ >> +Set Python stack printing."), _("\ >> +Show Python stack printing."), _("\ >> +Enables printing of Python stack traces."), >> + NULL, NULL, >> + &maintenance_set_cmdlist, >> + &maintenance_show_cmdlist); >> + >> +} > > If the list of python configuration variables grows, this will get out > of hand; I suggest sharing the init code regardless of HAVE_PYTHON. You mean having #ifdefs inside _initialize_python itself? > This patch is enough for a first NEWS entry. > > Otherwise OK :-) Awesome. Now working in a respin of the patch... -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center