from my .l :
[ \n\t]                 ;                  <<<< line 24
"("                     return( OPEN_P );  <<<< line 33
LIB                     return( LIB );     <<<< line 83


From my .y

lib_tag         : OPEN_P LIB QSTRING
OPEN_P
lib_tag_data
CLOSE_P
CLOSE_P
;


From the data :
...
(TEXT 'BAR00')))))

(LIB 'GS40_ARCH' (
(OBJECT 'POWERBUSTS' (
(ATTR 'COMMENTS'(
(TEXT

What I get :
--accepting rule at line 34 ("'BAR00'")
line #1085
--accepting rule at line 27 (")")
--accepting rule at line 27 (")")
--accepting rule at line 27 (")")
--accepting rule at line 27 (")")
--accepting rule at line 27 (")")
--accepting rule at line 24 ("
")
--accepting rule at line 33 ("(")
--accepting rule at line 83 ("LIB")
lafferror  : "syntax error"


--
___  _ ____       ___       __  __
/ _ )(_) / /_ __  / _ \___ _/ /_/ /____  ___
/ _  / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/   \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodlogy Group
Dallas, Texas, 214-480-4455,  b-patton@ti.com

[ Post a follow-up to this message ]

Billy N. Patton <b-patton@ti.com> wrote:
> from my .l :
> [ \n\t]                 ;                  <<<< line 24
> "("                     return( OPEN_P );  <<<< line 33
> LIB                     return( LIB );     <<<< line 83


>  From my .y

> lib_tag         : OPEN_P LIB QSTRING
>                    OPEN_P
>                    lib_tag_data
>                    CLOSE_P
>                    CLOSE_P
>                  ;


>  From the data :
> ...
>      (TEXT 'BAR00')))))

> (LIB 'GS40_ARCH' (
>    (OBJECT 'POWERBUSTS' (
>      (ATTR 'COMMENTS'(
>        (TEXT

> What I get :
> --accepting rule at line 34 ("'BAR00'")
> line #1085
> --accepting rule at line 27 (")")
> --accepting rule at line 27 (")")
> --accepting rule at line 27 (")")
> --accepting rule at line 27 (")")
> --accepting rule at line 27 (")")
> --accepting rule at line 24 ("
> ")
> --accepting rule at line 33 ("(")
> --accepting rule at line 83 ("LIB")
> lafferror  : "syntax error"

Impossible to say from the information you supply - perhaps your
assumption that the parser is in a state where the "(LIB" bit gets
parsed as a 'lib_tag' is wrong. All the debug output is just from
the tokenizer and doesn't tell you anything about the state the
parser is in (except the very last line;-).

Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

Jens.Toerring@physik.fu-berlin.de wrote:
> Billy N. Patton <b-patton@ti.com> wrote:
> 
>
>
> 
>
> 
>
>
> 
>
> 
>
> 
>
>
> Impossible to say from the information you supply - perhaps your
> assumption that the parser is in a state where the "(LIB" bit gets
> parsed as a 'lib_tag' is wrong. All the debug output is just from
> the tokenizer and doesn't tell you anything about the state the
> parser is in (except the very last line;-).
>
>                                       Regards, Jens
How do I get more debug information?
I've tried stepping through xxgdb, gdb and ddd but I thing the #line is
creating problems.  The debugger's stop on lines with comments.

I have the output file that gives state information,but if it has the
information I need, I'm too new to this.
I wrote this parser @ 15 years ago.  It worked then.  THe data has not
changed, but operating syteam, compiler, flex/bison and platforms have
all changed.



This is one of those things I did, it worked and never failed, so it was
knowledge lost over the years 

--
___  _ ____       ___       __  __
/ _ )(_) / /_ __  / _ \___ _/ /_/ /____  ___
/ _  / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/   \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodlogy Group
Dallas, Texas, 214-480-4455,  b-patton@ti.com

[ Post a follow-up to this message ]

Billy N. Patton <b-patton@ti.com> wrote:
> Jens.Toerring@physik.fu-berlin.de wrote: 
> How do I get more debug information?
> I've tried stepping through xxgdb, gdb and ddd but I thing the #line is
> creating problems.  The debugger's stop on lines with comments.

The "line #1085" is actually another piece of information that comes
from the parser, not the tokenizer, and tells you that it executes
the action on line 1085 of your .y file (that seems to be quite a
large beast of a parser!). Perhaps that's already enough information
to figure out in which state the parser is and if this is the state
you expect it to be in. Otherwise I would probably start sprinkling
the parser with printf()'s in order to make it easier to follow
what's happening...

> I wrote this parser @ 15 years ago.  It worked then.  THe data has not
> changed, but operating syteam, compiler, flex/bison and platforms have
> all changed.

And you might even have used lex on a completely different platform
instead if bison - they were even 15 years ago not all 100% identical
as far as I have read and have probably changed quite a bit. Does
bison at least work without printing warnings when you feed it the
.y file?
Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

Jens.Toerring@physik.fu-berlin.de wrote:
> Billy N. Patton <b-patton@ti.com> wrote:
> 
>
>
> The "line #1085" is actually another piece of information that comes
> from the parser, not the tokenizer, and tells you that it executes
> the action on line 1085 of your .y file (that seems to be quite a
> large beast of a parser!). Perhaps that's already enough information
> to figure out in which state the parser is and if this is the state
> you expect it to be in. Otherwise I would probably start sprinkling
> the parser with printf()'s in order to make it easier to follow
> what's happening...
>
> 
>
>
> And you might even have used lex on a completely different platform
> instead if bison - they were even 15 years ago not all 100% identical
> as far as I have read and have probably changed quite a bit. Does
> bison at least work without printing warnings when you feed it the
> .y file?
>                                      Regards, Jens

Yes and I get an output file that contain a lot of information I don't
quite understand.
I've put printf's in the .l and the .y.  It seems to be doing
everything right until it gets to the (LIB '***'
It prints the LIB and the space but is dying at the QSTRING
THis QSTRING is no different that the previous ones.

My Makefile has
laff_test:
bison --debug -v -d laff.y -p laff
flex -d -Plaff laff.l
$(CC) $(CFLAGS) -DDO_MAIN -DPRINTOUT laff.tab.c lex.laff.c -o laff


--
___  _ ____       ___       __  __
/ _ )(_) / /_ __  / _ \___ _/ /_/ /____  ___
/ _  / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/   \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodlogy Group
Dallas, Texas, 214-480-4455,  b-patton@ti.com

[ Post a follow-up to this message ]

Billy N. Patton <b-patton@ti.com> wrote:
> Yes and I get an output file that contain a lot of information I don't
> quite understand.

I also have always trouble understanding them - too much information
too densly packed;-)

> I've put printf's in the .l and the .y.  It seems to be doing
> everything right until it gets to the (LIB '***'
> It prints the LIB and the space but is dying at the QSTRING
> THis QSTRING is no different that the previous ones.

Are you sure it's the QSTRING? From the error message I would assume
that's it already the LIB token the parser is choking on. Can you make
the .l/.y files plus some sample input file downloadable?
[vbcol=seagreen]
> My Makefile has
> laff_test:
>          bison --debug -v -d laff.y -p laff
>          flex -d -Plaff laff.l
>          $(CC) $(CFLAGS) -DDO_MAIN -DPRINTOUT laff.tab.c lex.laff.c -o laff[/vbcol
]

That's exactly the same flags I typically use and that don't give me
any trouble. So I guess you should be fine with this.

Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]