2011/3/20 Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>:
> 2011/3/20 hom <obsidianhom(at)gmail(dot)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).
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. :)
In response to
pgsql-hackers by date
|Next:||From: Martijn van Oosterhout||Date: 2011-03-20 19:26:30|
|Subject: Re: Collations versus record-returning functions|
|Previous:||From: hom||Date: 2011-03-20 15:31:11|
|Subject: Re: I am confused after reading codes of PostgreSQL three week|