On Fri, 2011-06-24 at 12:04 -0600, Tom Tromey wrote:
I ran the checker against gdb and got an error:
Traceback (most recent call last):
File "/home/tromey/Space/Trunk/gcc-python-plugin/libcpychecker/__init__.py",
line 33, in on_pass_execution
check_pyargs(fun)
File
"/home/tromey/Space/Trunk/gcc-python-plugin/libcpychecker/PyArg_ParseTuple.py",
line 469, in check_pyargs
if stmt.fndecl.name == 'PyArg_ParseTuple':
AttributeError: 'NoneType' object has no attribute 'name'
../../archer/gdb/cli/cli-dump.c: In function ‘call_dump_func’:
../../archer/gdb/cli/cli-dump.c:787:1: fatal error: Unhandled Python exception raised
within callback
compilation terminated.
I am not certain, but perhaps this happens due to a call via a function
pointer.
The appended patch worked for me, at least in the sense that it removed
the error.
As it happens, I just ran into this one myself! (in my case, I'm trying
to run it on python itself).
Yes, my checker was barfing on calls through a function pointer.
I've already pushed this patch for this:
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commit;h=896b4...
I'm running into another problem, with format codes that specify a
PyObject subclass e.g "S" I'd coded these to expect e.g. a
PyStringObject**, but this is overspecifying it; there's plenty of valid
code that passes PyObject**. (but PyStringObject** would also be
valid).
So I'm working on fixing that now.
Also, the error location could be better here. E.g., in this case,
if
it used the location of the call statement, I could more easily see what
exactly the problem is. As it is the location refers to the closing
brace of the function.
Agreed.
BTW, was this function the final one in the source file?
There are two problems here:
- if a Python unhandled exception happens, the plugin reports it
(giving the Python traceback), and then issues a gcc error, which is
reported at the level of the C source code. Somehow we need to get gcc
to give a better location for that error: it knows which function the
error happened in. But it's better to fix the python script so that the
exception doesn't happen, of course.
- when issuing the warning from the script, we have to use the
gcc.Location. I've tried using using that of the arguments themselves,
but it tends to give me the location of the call. I'm not quite sure
where the information is getting lost.
I'm excited that you're trying it out on gdb. Are you able to compile
all of gdb with the checker script?
Cheers
Dave