This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC][patch 1/9] initial Python support
- From: Tom Tromey <tromey at redhat dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 29 May 2008 14:44:54 -0600
- Subject: Re: [RFC][patch 1/9] initial Python support
- References: <20080429155212.444237503@br.ibm.com> <20080429155304.288626880@br.ibm.com> <20080528205921.GA2969@caradoc.them.org>
- Reply-to: tromey at redhat dot com
>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
I've checked in fixes for a lot of the comments you've made. Thanks
for taking the time. It is clear we still have a lot to do.
Here, I've only commented on specific things requiring comment.
>> +#ifdef HAVE_PYTHON
>> +#include "python/python.h"
>> +#endif
Daniel> There are too many #ifdef's in the rest of GDB in this patch,
Daniel> IMO. Can python/python.h be included unconditionally, not
Daniel> include python-internal.h, and have the exposed interfaces
Daniel> error() when Python support is not compiled in?
I didn't touch Volodya's MI/varobj code, but I did the rest of this.
Daniel> In general I would prefer we not commit any FIXMEs. We can
Daniel> decide now what the right thing to do is and if there is room
Daniel> for future enhancement, that's not a FIXME any more :-)
Ok. I'm working my way through the new ones. Thiago, Volodya --
please look through the code you've written on the branch :-)
Daniel> Also, in general PyErr_Print is probably dumping to stderr?
Daniel> Output should go through GDB's error mechanisms, and in this
Daniel> case probably be part of the argument to error. Can you get
Daniel> it to return an error string instead?
Good question. I looked at the implementation of PyErr_Print, but it
is ~100 lines of C. That's kind of a lot to copy.
We can probably get just the exception's text -- without the entire
stack trace -- fairly easily. I will have to look into this.
Or, I think we can set sys.stderr and dump the exception, including
the whole trace, wherever we like. This may be more fragile. And, it
isn't clear to me that we want or need the whole trace.
Daniel> Speaking of which... a testsuite? :-)
Yeah -- we definitely need both a testsuite and documentation.
I'd guess we are all avoiding this.
Tom