Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!uwvax!uwmacc!uwmcsd1!leah!itsgw!batcomputer!pyramid!prls!mips!hansen
From: hansen@mips.UUCP (Craig Hansen)
Newsgroups: comp.sources.d
Subject: Re: How do you debug lex/yacc output?
Message-ID: <514@ollie.UUCP>
Date: Tue, 14-Jul-87 13:08:25 EDT
Article-I.D.: ollie.514
Posted: Tue Jul 14 13:08:25 1987
Date-Received: Thu, 16-Jul-87 07:36:00 EDT
References: <4897@milano.UUCP>
Lines: 29
Summary: strip cpp directives

In article <4897@milano.UUCP>, wex@milano.UUCP writes:
> I am writing in lex and yacc.  The yacc file has 181 terminals, 191
> nonterminals 399 grammar rules and 803 states, plus several hundred
> lines of C code to perform the semantic action.  Naturally, anything
> this big is bound to have bugs.  But dbx can't help me - it can't
> operate on the output of yacc (or at least I can't figure out how to
> get it to).

Debuggers are too implementation dependent for me or
anyone else to suggest an alternate debugger.

What I'd suggest is that you use yacc to explicitly generate the C code,
then use a "sed" or "awk" script to remove C preprocessor statements of the
form: # line xx "zz.y" from the code.  These cpp statements cause the source
line numbers within the yyparse procedure to get rather confused, and
simple-minded debuggers such as dbx can't hack them properly. What you'll
end up seeing at the "source" level is a big case statement containing the
semantic actions with the syntactic variables replaced with expressions of
the form: yypvt[-xx].type.

Even better is to make the semantic actions really simple, such as calls to
procedures that do the work.  That way, you will have little need to set
breakpoints within yyparse at all.

-- 
Craig Hansen
Manager, Architecture Development
MIPS Computer Systems, Inc.
...decwrl!mips!hansen