2011/3/20 Nicolas Barbier <nicolas.barb...@gmail.com>: > 2011/3/20 hom <obsidian...@gmail.com>: > >> I trace into scan.c because I want to known how the paser tree is >> built and I debug the source step by step. > > I suggest you learn how flex/bison work first. The contents of the *.c > files generated by flex/bison are not generally supposed to be > interpreted by humans, rather you should read their original sources > (*.l and *.y). > >> Then the eclipse pick up the scan.I and the excute order does not >> match the code. > > Eclipse seems to understand that any code corresponding to the > generated .c file actually originates in the .l file, but apparently > fails to match (some of?) the line numbers. OTOH, I cannot really > imagine how it is supposed to match them as long as you are not > executing lines that are literally copied from the .l file (e.g., as > long as the lexer or parser code itself is being executed), so that > may be normal. > > Again: Do not try to read the generated .c files, but rather read the > corresponding .l and .y files. The tarballs may include those > generated .c files, but as you will find out when checking out the > repository itself, they are not really considered "source" (i.e., they > are not included). When debugging, skip over the lexer and parser code > itself, just put your breakpoints in the C code in the .l and .y files > (I hope Eclipse might match *those* line numbers a least, and make the > breakpoints work). > > Nicolas >
Thanks Nicolas. I put breakpoints in scan.I but it doesn't work sometime. but it doesn't matter. I plan to spend more time on mmgr, storage, access. :) -- Best Wishes! hom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
