htf@castle.edinburgh.ac.uk (H T Fallside) (01/29/91)
Anyone have any suggestions about ways of getting dbx to behave sensibly
with a yacc generated parser as part of the program - ie indexing into the
source during debug ?
thanks in advance
hamish
[Yacc generates #line directives that let any sensible debugger use the .y
as the source file. If your dbx can't handle them, try gdb. -John]
--
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.michi@ptcburp.ptcbu.oz.au (Michael Henning) (01/31/91)
htf@castle.edinburgh.ac.uk (H T Fallside) writes: >Anyone have any suggestions about ways of getting dbx to behave sensibly >with a yacc generated parser as part of the program - ie indexing into the >source during debug ? There is not necessarily any sensible way to deal with #line directives in the generated .c file. The easiest thing is usually to pre-process the generated code with sed or some other tool to remove the #line directives before compilation. Michi. -- Michael Henning +61 75 950255 Pyramid Technology +61 75 522475 FAX Research Park, Bond University michi@ptcburp.ptcbu.oz.au Gold Coast, Q 4229, AUSTRALIA uunet!munnari!ptcburp.oz!michi [My experience is quite different; I've found it quite useful to put in breakpoints and single step by line in the .y file. If you don't like the #line directives, the -l flag to yacc prevents them. -John] -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
meissner@osf.org (02/01/91)
| htf@castle.edinburgh.ac.uk (H T Fallside) writes: | | >Anyone have any suggestions about ways of getting dbx to behave sensibly | >with a yacc generated parser as part of the program - ie indexing into the | >source during debug ? Michael Henning writes: | There is not necessarily any sensible way to deal with #line directives in | the generated .c file. The easiest thing is usually to pre-process the | generated code with sed or some other tool to remove the #line directives | before compilation. And John writes: | [My experience is quite different; I've found it quite useful to put in | breakpoints and single step by line in the .y file. If you don't like the | #line directives, the -l flag to yacc prevents them. -John] It depends on what your object format is, whether it can handle #line directives or not. There are two inter-related problems -- whether multiple files are handled within one object file format, and whether line numbers within a function can vary outside of the range of the function's start/end (or even if they must be monotonically increasing). Typical parser generators, require changing both the filename and line number within a function to switch between the actions and rules files. Going over the object files I've dealt with in the past gives: 1. Berkeley stabs ================== This allows multiple .file and/or .line directives. 2. System V.[0123] coff ======================== Pure COFF only allows one file in a compilation unit. Line numbers are relative to the start of the function, and must be positive, which makes debugging inlines a pain as well. 3. Third Eye ECOFF (used on MIPS) ================================== ECOFF allows multiple files within a compilation unit, though you cannot change the file within a function boundary. Line numbers are relative to the start of the function, though negative values are allowed. You must not have more than 65K of lines separating two adjacent statements. 4. OSF/rose ============ At present, we use Berkeley stabs and do not have a problem. 5. Dwarf (System V.4) ====================== I can't find in my dwarf documents whether this is allowed or not, though I remember a comment about trying to remove the restriction that lines for a file be contigous, which would mean that you possibly would have to have a separate file section for each #line that introduced a filename, different from the previous. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
djones@decwrl.dec.com (Dave Jones) (02/01/91)
> Anyone have any suggestions about ways of getting dbx to behave sensibly > with a yacc generated parser as part of the program - ie indexing into the > source during debug ? > > thanks in advance, hamish > [Yacc generates #line directives that let any sensible debugger use the .y > as the source file. If your dbx can't handle them, try gdb. -John] The BSD (original) yacc has a problem in that its has some #line directives for the .y file before the code for yyparse. Thus, when the program counter is somewhere in the yaccpar part of yyparse (not in the user-defined actions), dbx displays the .y file anyway, and appears to hop around in that file at random. To make it sensical, you need only to add a #line directive just before the declaration of yyparse. I once posted a little nawk (new AWK) script to run over your y.output file, and somebody sent me mail containing a small improvement over it. I can't find them now, but the following will give you the idea. At the time I posted the original, our moderator - (Hi, John) - tagged it with a comment to the effect that the script was incorrect, and that it appeared to "do the opposite of what is wanted." Well, John, look again. It will still display the .y file when executing the actions defined there. What it will not do is display the .y file while executing instructions from yaccpar. Here 'tis: ^^^^ snip ^^^^ snip ^^^^ snip ^^^^ snip ^^^^ snip ^^^^ snip ^^^^ snip /^yyparse/ { print "# line " NR + 1 " \"y.tab.c\"" print $0 next } { print $0 } [I don't think it was me, as far as I can tell this was never in comp.compilers before. -John] -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.