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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
