On Wed, 20 Aug 2008, Chuck Blake wrote:
> Something worth mentioning at this point is that *proper* preprocessor
> integration has unelaborated and perhaps unconsidered subtleties.
>
> You should be wary of things like cpp caring about lexical structure
> (not expanding macros inside text that looks like a C strings,
> deleting text you don't want because it looks like a C comment,
> as in glob('''foo/*'''), and so on.
Yes, these are good points. I don't want to go down the path of trying to
add our own special pre-processing language into Cython...
> There are also consequences for the main language parser since one
> wants to propagate source coordinates to be a good toolchain citizen.
> Pyrexc/Cython are already not such good citizens. They could but
> do not put file and line number directives in the generated C.
>
> Yes, perhaps in Pyrex's/Cython's case every other output C line would
> need to be a #line and one may want to turn it off to look at generated
> code. Yet, it seems to me the default should be to generate these
> for naive or "regular" users who upon seeing an uninitialized variable
> warning or what have you at line "foo.pyx:55" not at some line in the
> generated code. Those who want #file/#line off (to debug the code
> generator or declutter the generated code) are likely more empowered
> to easily disable #file/#line generation than those confused by source
> coordinates and wanting "unused variable" and "unitialized variable"
> type warnings. :)
As a bit of defense, this is because nearly all C-level compile
warndings/errors are not usually tied to a specific line in a .pyx file
(e.g. unsed variable warnings are nearly always automatically created
ones). And when trying to diagnose segfaults pyx file line numbers are
usually not granular enough to figure out what is going on (for me at
least). The correspondance between C and pyx code is far from one-to-one,
and likely to diverge even further in the future.
> Even more significantly than things like data flow gcc warnings, this
> would let me set a breakpoint in GDB like "breakpoint foo.pyx:55".
> Yes, gdb doesn't yet understand Cython, and I'd have to use "inf loc"
> or something to look at the local variables, but it would be nice to
> even just make it easier to stop at the right Cython function (rather
> than mangling or mucking about in source code).
If you declare function names to be "public" then the name will not get
mangled.
> Source coordinate propagation is a good thing. I actually have a
> little profiling toolkit that would be able to tell me which line
> numbers of pyx were my performance problems, if only the coordinates
> were propagated.
That sounds very cool. I would love to have something like that.
> If you really want to ditch include/IF/DEF/DEFINED/etc. and use some more
> general tool, that tool could/should generate #file or #line directives.
> Then on the input side of the equation, Cython should parse those in and
> propagate them (this INPUT side of things is on the original Pyrex TODO list,
> but strangely the OUTPUT which is needed to make 'gdb' or 'addr2line' and
> such easy to use wasn't on the list -- there are some e-mail refs, though,
> so this may have all come up before). { Cython actually has discretion to
> require the input directives be spelled some way besides "#file" if you don't
> want to support cpp. The # spelling seems pretty reasonable to me. Cython
> just has to actually parse that kind of comment rather than ignore it. }
>
> Just some issues to keep in mind for anyone that wants to work on this...
I would be in favor of an option that outputs #file and #line directives.
Perhaps we could accept this (or something similar) as input too, though
I'm not sure what the best syntax is.
I think the better solution for this is to output a symbol table which
relates Cython line numbers/variables/functions/... with their C
counterparts (much like gcc does with -g) which debuggers and profilers
could read.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
